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THE  MANAGEMENT  FRAMEWORK  FOR 
PROCESS  IMPROVEMENT: 

A  Guide  to  the  Methodology 


SECTION  1.  INTRODUCTION 

1.1  The  Third  Industrial  Revolution 

American  enterprise  is  caught  up  in  a  massive 
restructuring  not  seen  in  this  country  since  the 
second  industrial  revolution,  which  introduced  the 
factory  system  and  dramatically  changed  all  aspects 
of  American  life.  This  sea  change  is  being 
described  as  a  paradigm  shift  that  requires  a  new 
context  for  leadership  and  management  practice  in 
all  sectors  of  our  economy.  In  his  book.  The  Third 
Wave,  published  in  1980,  Dr.  Alvin  Tofler  described 
this  new  paradigm  as  the  information  age.  We  are 
just  now  beginning  to  understand  the  full  impact  of 
his  prophetic  writings. 

Government  in  general,  and  the  Department  of 
Defense  in  particular  are  caught  up  in  this 
phenomenon,  which  some  authorities  call  the  third 
industrial  revolution  and  others  call  the  information 
age.  We  cannot  stop  it.  We  cannot  avoid  it.  We 
can,  however,  tap  into  the  power  generated  by  the 
change  forces  at  work  here  and  use  it  to  transform 
the  Department  in  ways  that  will  take  full  advantage 
of  the  capabilities  inherent  in  an  information  age 
economy. 

The  term  information  age  is  no  more  restricted 
to  computers  and  data  than  the  term  industrial  age 
is  limited  to  machines  and  materials.  The 
information  age  concept  is  all-encompassing  and 
affects  all  facets  of  our  culture,  society,  and 
economy.  Therefore,  all  elements  that  make  up  the 
Department — our  mission,  vision,  culture, 
leadership,  management,  human  resources,  products 
and  services,  processes,  and  systems — ^must  be 
examined  as  we  endeavor  to  help  guide  DoD  into 
this  new  age. 


1.2  The  Paradigm  Shift 

The  information  age  represents  a  paradigm 
shift  in  the  way  enterprises,  especially  large 
enterprises,  are  organized  and  how  they  function. 
Experience  has  shown  that  there  is  great  resistance 
to  change  within  organizations  when  they  are  faced 
with  massive  dislocations  brought  on  by  the  forces 
of  change.  History  also  tells  us  that  usually  and 
eventually  the  forces  of  change  prevail  over  those 
who  resist.  These  are  the  six  most  important 
elements  that  have  to  be  reckoned  with: 

1.2.1  Global  Economy.  Competition  is  no  longer 
constrained  by  national  boundaries.  Every  decision 
made  by  large  enterprises,  including  governments, 
has  profound  impacts  all  over  the  world.  Products, 
services,  and  ideas  flow  freely  across  national 
borders.  Free  enterprise  and  the  discipline  of 
markets  has  and  is  prevailing  over  planned 
economies  and  allocation  of  goods  and  services. 
The  competition  for  skilled  labor  and  professional 
skills  pits  non-profit  and  governmental 
organizations  against  for-profit  and  private  sector 
concerns.  Privatization  and  out-sourcing  are 
increasing  as  the  competition  for  talent  triumphs 
over  organizational  stagnation  and  employee 
loyalty. 

1.2.2  Information  Highway.  Information  is  the 
new  capital  of  the  information  age.  Those 
enterprises  that  best  learn  to  share  information, 
rather  than  control  it,  will  succeed.  The  availability 
of  information  and  the  means  to  both  transform  it 
and  transmit  it  determines  how  efficiently  and 
effectively  an  organization  can  re-order  its  business 
processes  to  respond  to  changing  demands  for 
products  and  services  in  an  unforgiving  global 
marketplace. 
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1.2.3  Employee  Empowerment.  The  factory  model 
for  organizing  and  managing  employees  is  a  second 
industrial  revolution  paradigm  that  still  prevails  in 
most  modem  enterprises.  This  model  was  developed 
in  an  age  when  education  was  at  a  premium  and  the 
supply  of  unskilled  or  semi-skilled  workers  was 
endless.  Hierarchies  of  management  did  the  thinking 
and  planning  while  armies  of  workers  followed  the 
mle  book  and  did  what  they  were  told.  In  the 
information  age,  educated  and  skilled  workers 
organized  into  teams  need  only  information  and  the 
authority  to  act  for  the  enterprise  to  be  successful. 

The  role  of  the  manager  is  shifting  from  giving 
direction  and  rating  performance  to  individual 
coaching  and  team  facilitation. 

1.2.4  Virtual  Corporation.  As  the  walls  between 
nations  become  porous,  so  too  are  the  fences  that 
separate  enterprises  coming  down.  The  enterprise 
will  no  longer  be  a  physical  entity  organized  around 
structure,  but  an  ephemeral,  intangible  entity  loosely 
associated  in  alliances  to  serve  customer  needs.  The 
military  establishment  is  no  stranger  to  this  concept 
as  armies  have  always  been  formed  out  of  divisions 
and  specialized  battalions  for  a  specific  purpose,  and 
then  reformed  as  events  warrant. 

1.2.5  Focus  on  Core  Competencies.  The  vertically 
integrated  enterprise  was  well  suited  to  insulate  the 
second  industrid  revolution  economy  from  the 
ravaging  forces  of  rapid  change.  It  was  possible  for  a 
single  company  to  control  a  commodity  like  gasoline 
from  well-head  to  gas  tank.  The  new  paradigm 
mandates  that  an  organization  discover  what  few 
things  it  does  well,  better  than  anyone  else,  then 
allocate  all  capital  and  human  resources  to  doing 
those  few  things.  More  and  more  business  leaders 
are  selling  off  or  discontinuing  businesses  where  they 
are  not  the  leading  producer  or  at  least  the  second 
leading  producer.  Governmental  organizations  are 
turning  more  and  more  to  out-sourcing  or 
privatization  when  they  cannot  excel  in  an  endeavor. 

1.2.6  Demand  for  Quality  and  Service.  The  new 

consumer  is  an  educated,  discriminating  buyer  of 
goods  and  services  and  demands  value  in  the  form  of 


high-quality,  low-cost,  and  rapid  service.  Products 
and  services  must  meet,  if  not  exceed,  the 
expectations  of  sophisticated  customers.  This  rule 
applies  also  to  business  buyers  as  well  as  consumers 
of  government  services.  The  concept  of  a  captive 
customer  is  bound  by  the  old  paradigm  even  with 
respect  to  consumers  of  government  services. 

1.2.7  The  New  Paradigm  and  the  Department  of 
Defense.  All  of  the  attributes  of  the  information  age 
have  impact  on  the  ability  of  the  Department  of 
Defense  to  carry  out  its  mission.  While  the 
Department  has  no  direct  competitor  in  the  usual 
meaning  of  the  term,  it  does  compete  in  the 
marketplace  for  products,  services,  ideas, 
employees,  funding,  and  support  from  the  citizenry 
and  their  political  leaders.  The  Department  cannot 
isolate  itself  from  the  transforming  influences 
inherent  in  the  new  paradigm. 

1.3  TVansforming  the  Department  of  Defense 

Desert  Storm  effectively  demonstrated  the 
capabilities  of  our  high-technology  weapons 
systems  and  proved  the  efficacy  of  our  command 
structure  resulting  from  the  1986  Goldwater- 
Nichols  Act.  But  it  also  revealed  a  pressing  need  to 
reexamine  the  “tooth-to-tail”  relationship  between 
combat  and  support  systems.'  We  have  come  to 
realize  that  we  need  to  restructure  the  Department 
around  a  new  enterprise  model  that  will  include  all 
functional  areas  in  the  sustaining  base  with 
responsibility  for  all  aspects  of  our  strategic  and 
tactical  mission. 

The  DoD  process  improvement  program,  a 
part  of  the  Corporate  Information  Management 
(CIM)  initiative  under  the  Assistant  Secretary  of 
Defense  for  Command,  Control,  Communications, 
and  Intelligence  (ASD  (C^I)),  is  designed  to  provide 
the  mechanism  for  effecting  this  transformation. 

We  have  already  obtained  significant  results  in  the 
fimctional  areas  where  process  improvement 
principles  have  been  applied.  But  as  we  gained 
experience  with  the  program,  we  realized  that  we 
needed  an  overarching  methodology  to  guide 


1  Defense  for  a  New  Era,  Les  Aspin  and  William  Dickinson,  1992,  page  34. 
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improvement  efforts  on  the  massive  scale  required 
to  achieve  results  consistent  with  our  current 
national  defense  policy.  This  methodology  is  also 
needed  to  assist  the  Department  in  realigning  its 
business  and  functional  processes  to  maximize  their 
potential  and  performance  in  the  new  age. 

1.4  Need  for  a  Process  Improvement 

Methodology 

The  Framework  for  Managing  Process 
Improvement  (Framework)  described  in  this 
guidebook  is  the  response  to  the  need  for  an 
overarching  methodology.  The  Framework  consists 
of  a  comprehensive  methodology  for  performing 
process  improvement  projects  and  is  applicable  in 
all  functional  areas  in  the  Department.  It  supports 
three  levels  of  improvement  efforts  that  we  include 
under  the  definition  of  functional  process 
improvement  (FPI). 

■  Continuous  Process  Improvement  (CPI) 
that  reduces  variation  in  the  quality  of 
output  products  and  services  and 
incrementally  improves  the  flow  of  work 
within  a  functional  activity. 

■  Business  Process  Redesign  (BPR)  that 
removes  non- value  added  activities  fi'om 
processes,  improves  our  cycle-time 
response  capability,  and  lowers  process 
costs. 

■  Business  Process  Reengineering  (BRE) 
that  radically  transforms  processes 
through  the  application  of  enabling 
technology  to  gain  dramatic 
improvements  in  process  efficiency, 
effectiveness,  productivity,  and  quality. 

The  Framework  was  developed  after  an 
intensive  period  of  research  into  Ae  theory  and 
practice  of  process  improvement.  The  literature 
related  to  Functional  Process  Improvement  (FPI), 
and  material  about  the  practice  of  Total  Quality 
Management  (TQM)  and  Total  Quality  Leadership 
(TQL),  were  thoroughly  examined. 


The  findings  indicated  that  both  process 
improvement  and  TQM  are  concerned  with  the 
same  issues  and  seek  to  achieve  the  same 
objectives,  but  approach  the  problem  from  different 
perspectives.  By  taking  the  best  practices  and 
techniques  from  each  discipline,  we  developed  a 
methodology  that  represents  breakthrough  thinking 
into  the  problem  of  applying  quality  management 
principles  in  a  services  organization. 

Recent  literature  suggests  that  others  are 
arriving  at  similar  conclusions.  Edward  Fuchs, 
Director,  Quest  Division,  AT&T  Laboratories, 
resolves  the  confusion  over  the  role  of  incremental 
improvement,  a  long-standing  component  of  TQM, 
versus  the  more  recently  introduced  notion  of 
reengineering,  by  clarifying  their  different 
perspectives — one  being  primarily  technical,  the 
other  focusing  on  leadership: 

1 .  Where  the  performance  gaps  are  large, 
reengineering  is  the  proper  approach. 
Where  they  are  small,  incremental 
improvement  provides  the  required 
results. 

2.  Incremental  improvement  is  an  extension 
of  past  performance  without  the  driving 
force  of  a  leader.  Reengineering  is 
driven  by  the  pull  of  the  future,  the 
vision  of  the  leader,  or  the  target  to 
which  the  company  is  aiming.^ 

Clearly  both  process  improvement  and  process 
reengineering  concepts  are  being  incorporated  into 
quality  management  principles  and  practices.  Any 
methodology  developed  to  guide  improvement 
efforts  must  be  comprehensive,  and  must  be  based 
on  best  practices  wherever  they  are  found.  To 
confirm  this  theory,  the  Framework  was 
benchmarked  in  twelve  private  and  public  sector 
organizations  known  to  have  achieved  success  in 
process  improvement.  The  benchmark  partners 
included  two  winners  of  the  Malcolm  Baldrige 
National  Quality  Award  and  those  who  have 
achieved  ISO  9000  certification.  We  found  that  • 
having  a  unified  methodology  is  an  important 
component  of  success  in  process  improvement 
efforts  in  large  organizations. 


2  "Total  Quality  Management  from  the  Future:  Practices  and  Paradigms,"  Eduward  Fuchs,  Quality  Management 
Journal,  October  1993. _ _ 
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1.5  Advantages  of  the  Framework 

Methodology 

Based  on  research,  benchmark  results,  and 
experience  to  date  using  the  Framework,  the 
methodology  has  undergone  three  major  revisions. 
This  document  describes  the  latest  in  what  will  be  a 
continuing  series  of  improvements  building  on 
Department  successes  with  process  improvement. 
Draft  5.0  of  the  methodology  offers  these 
advantages  and  benefits: 

■  The  Department  owns  the  methodology 
and  therefore  has  complete  control  over 
its  continuing  development. 

■  The  methodology  is  vendor-independent 
and  as  such  provides  a  neutral  resource 
for  use  by  all  contractors  and  Department 
employees. 

■  The  methodology  is  comprehensive — ^it 
■  covers  all  phases  of  process 

improvement  from  mission  development 
through  deployment  of  improved 
processes. 

■  The  methodology  is  consistent  with  the 
principles  ordained  by  such  authorities  as 
Deming,  Juran,  Taguchi,  Hammer, 
Davenport,  and  others. 

■  The  concept  of  a  single.  Department¬ 
wide  methodology  supports  the  cross¬ 
functional  training,  teaming,  and 
performance  efforts  needed  to  address 
complex  fimctional  processes  and  builds 
an  experience  base  that  is  deployable 
wherever  needed. 

■  The  methodology  is  compatible  with 
techniques  and  tools  already  established 
in  the  Department  such  as  groupware, 
IDEF  modeling,  activity-based  costing, 
functional  economic  analysis,  and  life 
cycle  project  management. 


1.6  Characteristics  of  the  Framework 

Methodology 

The  Framework  describes  twenty-five  specific 
steps,  organized  into  six  phases,  which  guide 
functional  users  through  the  improvement  process 
from  mission  validation  to  post-implementation 
assessment.  The  phases,  which  are  fully  described 
in  this  document  are: 

■  Strategic  and  Business  Planning 

■  Process  Improvement 

■  Change  Management:  Organizational 

■  Change  Management:  Technical 

■  Enterprise  Engineering 

■  Project  Execution. 

Each  phase  is  divided  into  steps  that  clearly 
describe  the  tasks  to  be  performed,  the  deliverables 
to  be  produced,  and  the  recommended  techniques 
and  tools  that  can  be  used  to  produce  the 
deliverables. 

The  Framework  concept  includes  an  integrated 
documentation,  training,  and  support  package  (also 
described  in  this  document),  which  will  enable 
functional  managers  and  employees  to  apply  the 
methodology  with  confidence  in  their  own 
organizational  unit. 

Joseph  Juran,  one  of  the  pioneers  in  quality 
management  and  process  improvement,  gives  three 
imperatives  for  implementing  great  change  in  an 
organization:  unwavering  commitment  from  senior 
leadership,  a  context  for  coordinating  change 
throughout  the  organization,  and  the  necessary  tools 
to  bring  about  the  change.^ 

With  a  comprehensive  methodology  in  place 
(Juran’s  second  point),  the  Department  can  move 
more  quickly  and  more  certainly  toward 
restructuring  critical  defense  processes  in  support  of 
our  primary  mission,  and  ensure  that  the 
Department  can  strengthen  the  relationship  between 
tooth-to-tail  systems.  This  in  turn  will  also  help  us 
complete  the  restructuring  process  currently  under 
way  within  the  Department  with  less  risk  of 
compromising  our  readiness,  capability,  and 
security. 


3  Juran  on  Quality  by  Design,  J.M.  Juran,  The  Free  Press,  New  York,  1992. 
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SECTION  2.  PROCESS  MANAGEMENT  AND  IMPROVEMENT 


The  hierarchical  (vertical)  organization  served 
the  needs  of  industrial  age  enterprises  well.  The 
organization  of  work  into  like  functions  is  suited  to 
the  needs  of  an  uneducated  work  force.  It  simplifies 
employee  supervision  and  training,  maximizes 
managerial  span  of  control,  and  has  little 
dependence  on  the  free  flow  of  information. 

A  new  model  is  needed  for  information  age 
enterprises  and  is  indeed  enabled  by  the  capabilities 
of  the  information  age.  Work  can  be  organized  and 
managed  as  an  end-to-end  process,  rather  than  as 
the  sum  of  disjointed  functions.  The  process 
management  model  is  well-suited  to  the  promise  of 
the  new  paradigm.  Once  the  concept  of  process 
management  is  firmly  rooted  in  the  enterprise,  it 
becomes  possible  to  organize  process  improvement 
programs.  Outside  a  framework  of  process 
management,  process  improvement  programs  have 
little  chance  of  lasting  success. 

2.1  Process  Management  Principles 

The  concept  of  process  management  is  not 
new.  It  has  been  practiced  on  the  factory  floor  for 
years.  Process  management  became  possible  in 
manufacturing  as  machines  began  replacing  manual 
labor,  and  information  and  communication 
networks  became  available  to  control  the  machines. 
Work  flow  was  simplified,  product  quality  was 
increased,  cycle  time  was  reduced,  and  process 
costs  had  nowhere  to  go  but  down.  Today,  there  are 
entire  factories  with  processes  so  well  designed  that 
no  humans  are  needed  except  for  emergencies, 
maintenance,  and  enhancements.  And  it  is  possible 
to  buy  a  small  high-quality  color  television  for  the 
price  of  a  meal  for  two  at  a  better  restaurant. 

It  is  interesting  to  note  that  while  the  typical 
service  corporation  today  is  patterned  after  the  old- 
style  factory  with  its  manually-intensive, 
functionally-based  division  of  labor  concept,  the 
new-age  service  corporation  is  being  modeled  after 
the  modem  industrial  corporation  and  its  automated 
end-to-end  processes. 


2.1.1  Functions  and  Processes.  A  process  is 
simply  the  largest  unit  referring  to  the  flow  of  work 
through  an  enterprise  beginning  with  external 
suppliers  and  ending  with  external  customers. 
Along  the  way,  value  is  added  at  each  step  through 
a  series  of  transformations  involving  the 
consumption  of  resources  within  an  established 
control  (rale-based)  framework.  Processes  may  be 
decomposed  into  smaller  units  beginning  with 
subprocesses  and  continuing  to  activities,  tasks, 
and  operations.  The  principles  are  the  same, 
regardless  of  the  level  of  work  transformation 
observed. 

A  function  is  a  specified  type  of  work  applied 
to  a  product  or  service  moving  within  a  process. 
Functions  are  described  in  the  typical  hierarchical 
organization  chart,  which  in  effect  breaks  down 
functions  from  the  chief  executive  office  of  the 
enterprise  through  successive  layers  of 
management  to  the  individual  worker  who  touches 
the  product  or  service,  or  who  faces  the  customer. 
As  work  crosses  functional  boundaries,  internal 
suppliers  and  internal  customers  are  created,  and 
responsibility  for  the  resources  and  controls  applied 
to  the  work  changes  hands. 

This  is  illustrated  in  Figure  2-1,  which  shows 
a  process  moving  through  two  functions.  Function 
A  sets  the  rales  for,  and  controls  the  resources 
assigned  to.  Activity  1.  Function  B  controls  and 
funds  Activity  2.  Function  B  is  the  internal 
customer  of  Function  A.  Much  of  the  challenge  of 
process  management  is  optimizing  the  transition  of 
processes  across  functional  boundaries. 

In  a  fiinctionally-driven  enterprise,  processes 
are  organized  around  structure  or  functions.  In  a 
process-driven  enterprise,  structures  and  functions 
are  organized  around  processes.  This  is  the 
fundamental  reason  that  meaningful  process 
improvement  cannot  succeed  in  a  hierarchical 
enterprise.  In  such  organizations,  processes  will 
always  be  suboptimized — somewhat  distorted — ^to 
fit  organizational  structure. 
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Figure  2-1 .  Process  and  Functions 


When  work  is  managed  by  function, 
manage  naturally  en^^iasize  lesomoe  ccxisun^cxiby  unit 
of  work  and  the  rigid  application  of  controls  or 
rules.  Because  employees  are  strongly  motivated  to 
follow  functional  rules  and  conserve  resources, 
relationships  with  suppliers  and  customers  are  not 
optimal.  When  work  is  managed  by  process, 
managers  emphasize  working  with  suppliers  and 
serving  customers  within  the  context  of  controls  and 
resources.  In  this  situation,  employees  are 
motivated  to  focus  on  product  and  service  quality, 
customer  service,  and  fast  response  to  exceptional 
situations. 

Most  large  organizations  have  from  five  to 
twenty  processes.  Processes  are  identified  during 
business  systems  planning  activities  and  mapped  to 
the  organizational  structure.  This  forms  the  basis 
for  building  cross-functional  teams. 

Process  management  as  a  business  model  has 
positive  effects  on  organizational  dynamics 
including  manager-employee  and  peer-to-peer 
relationships.  The  focus  for  organizational  activity 
within  a  process  is  on  serving  stakeholder  interests 
and  that  becomes  the  basis  for  empowerment,  self- 


motivation,  personal  esteem,  recognition,  and 
rewards.  Turf  battles,  infighting,  and  pettiness  must 
decrease  as  the  focus  shifts  from  a  preoccupation 
with  internal  concerns  to  one  of  serving  those  who 
have  interests  in  process  performance. 

1.12  Process  Stakeholders.  There  are  four  classes 
of  process  stakeholders — ^people  who  have  a 
defined  relationship  or  stake  in  process 
performance.  They  include  customers,  suppliers, 
higher  authority,  and  resource  providers.  Each  has  a 
different  interest  in  the  process,  defines  process 
performance  success  differently,  and  benefits  from 
process  performance  in  different  ways. 

Furthermore,  interests,  success  criteria,  and 
expected  benefits  vary  both  with  the  nature  of  the 
enterprise  (public  or  private),  and  with  the  purpose 
of  the  process. 

Figure  2-2  shows  the  stakeholder  classes  and 
the  principal  ways  in  which  they  relate  to  a  single 
process. 

■  Customers.  Customers  are  the 

recipients  and  users  of  the  products  and 
services  produced  by  the  process.  In  for- 
profit  enterprises,  customers  buy 
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Figure  2*2.  Process  Stakeholders 


products  and  services,  and  customer 
satisfaction  can  be  measured  in  such 
terms  as  market  share  and  market 
penetration.  In  government  enterprises, 
customers  receive  products  and  services 
either  on  a  fee  basis  or  as  an  entitlement. 
Customer  satisfaction  must  usually  be 
measured  in  indirect  ways  such  as  degree 
of  support  for  process  owners,  relocation 
from  one  jurisdiction  to  another,  public 
opinion  polls,  or  special  interest  group 
activity. 

■  Suppliers.  Suppliers  provide  the  inputs 
to  a  process,  which  consist  of  materials 
and  data.  Suppliers  generally  desire 
strong  partnership  relations,  exclusivity, 
100%  acceptance  of  inputs,  more 
business,  and  fast  payment. 

■  Higher  Authority.  Higher  authority  is 
defined  as  those  entities  outside  the 
process  that  set  rules,  requirements, 
standards,  constraints,  and  budgets  on 
process  performance.  Their  interests 
include  conformity,  low-risk  operations, 
satisfaction  of  functional  and  business 


objectives  and  goals,  and  process 
stability.  Higher  authority  is  often,  but 
not  always,  the  voice  of  functional 
management  within  the  enterprise  with 
respect  to  subprocesses  and  activities. 

■  Resource  Providers.  Resource 

providers  fund  process  operations  with 
facilities,  equipment,  machines,  and 
labor.  Everything  consumed  in  whole  or 
in  part  is  considered  a  process  resource. 
Resource  providers  are  interested  not 
only  in  conserving  resources  and  return 
on  invested  assets,  but  also  in  the 
inherent  benefits  of  the  process  itself, 
apart  from  the  output  product  and 
services.  Resource  providers  are  usually 
citizens  in  government  enterprises  who 
speak  through  their  elected 
representatives.  For  instance,  in  the  case 
of  the  Department  of  Defense,  resource 
providers  (citizens)  do  not  use  the 
weapons  systems  and  materiel  produced 
by  defense  processes,  but  they  do  enjoy 
the  benefits  of  peace  and  freedom  that 
result  from  defense  processes. 
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Process  management  consists  in  part  of 
satisfying  the  diverse  interests  of  all  process 
stakeholders  in  the  most  optimum  fashion.  It  also 
means  establishing  and  maintaining  a  working 
environment  that  balances  the  interests  of  process 
stakeholders  with  those  who  labor  within  the 
process. 

2.1.3  Performance  Measures.  Process 
management  views  work  in  terms  of  objectives, 
goals,  and  strategies  within  the  context  of  an 
enterprise — its  unique  organization  and  technology. 
Process  management  relies  on  feedback  to  evaluate 
and  improve  process  performance,  so  establishing 
meaningful  measures  is  a  primary  consideration. 

There  are  four  all-inclusive  categories  of 
performance  measures.  Specific  measures  within 
these  categories  provide  the  basis  for  evaluating 
both  the  satisfaction  of  stakeholder  interests  and  the 
performance  of  all  process  participants.  The  four 
categories  of  performance  measures  are 
conformance  to  standards,  fitness  for  purpose, 
process  cycle  time,  and  process  costs.  The  first  two 
categories  are  effectiveness  measures,  the  last  two 
are  efficiency  measures. 

■  Conformance  to  Standards  (CTS). 
Conformance  to*standards  measures  are 
concerned  with  product  and  process 
quality  with  respect  to  a  norm.  CTS 
measures  the  factors  of  customer 
acceptance  of  a  product,  service,  or 
deliverable;  number  of  rejects;  adherence 
to  procedures;  test  results;  budget 
performance;  compliance  with  public 
law,  statutes,  and  regulations;  and  issues 
associated  with  health,  safety,  and 
security. 

There  must  be  a  well-documented  or 
illustrated  standard  in  place.  The 
standard  must  state  the  requirements,  the 
authority  for  the  standard,  and  the 
applicability.  New  standards  of 
performance  should  be  validated  before 
being  put  into  service  for  a  given 
process.  Benchmarking  is  a  particularly 
good  technique  to  use  in  establishing 


standards  of  performance  in  this 
category. 

While  all  four  process  stakeholders  are 
concerned  with  CTS,  Higher  Authority  is 
particularly  interested  because  it  is  the 
source  for  most  conformance  standards. 
Customers  are  also  interested  in  CTS  as 
it  applies  to  output  products  and  services. 

■  Fitness  for  Purpose  (FFP).  Fitness  for 
purpose  measures  are  focused  on  the 
degree  to  which  a  given  interaction 
between  a  stakeholder  and  the  process 
meets  requirements  or  satisfies  an 
objective.  FFP  measures  such  factors  as 
how  well  a  product  or  service  satisfies 
(meets  requirements)  or  even  excites 
(exceeds  requirements)  customers. 
Customization,  flexibility,  and 
responsiveness  are  qualities  that  generate 
FFP  measures. 

FFP  also  applies  to  other  stakeholders. 
Higher  Authorities  need  to  measure  the 
relevance  of  standards,  rules,  and 
regulations  to  the  processes  on  which 
they  are  imposed.  Suppliers  are 
becoming  more  proactive  in  supplying 
processes  with  just  enough  value-added 
materials  and  data  to  meet  process 
requirements  with  a  minimum  of  waste. 
Resource  providers  are  concerned  with 
providing  suitable  facilities,  equipment, 
and  funding  vehicles  to  maximize 
process  performance. 

■  Process  Time  (PTM).  Process  time 
measures  are  concerned  with  process 
cycle  time,  throughput,  and 
responsiveness.  But  process  time  is  also 
a  reliable  surrogate  measure  for  process 
cost.  This  is  because  process  costs  are 
consumed  over  time  and,  in  general,  the 
less  time  a  process  takes  to  complete  a 
cycle  or  produce  a  product,  the  lower  the 
cost.  Many  leading  organizations  focus 
on  reducing  process  time  rather  than  on 
reducing  process  cost.  As  a  result,  they 
improve  cycle  time  while  automatically 
reducing  process  cost. 
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Process  time  measures  fall  into  three 
subcategories.  Operations  time  is 
defined  as  the  time  spent  within  a 
process  transforming  inputs  into  outputs 
by  adding  value  to  the  inputs.  It  is  the 
direct  application  of  resources  or  factors 
of  production  in  making  the 
transformation.  Non-value  added  time  is 
time  spent  in  the  process  other  than 
operations  time  or  quality-related  time 
(described  next).  It  includes  delay  or 
wait  time,  meetings  and  report  writing, 
supervision  and  oversight,  compliance 
with  unnecessary  or  inappropriate 
regulations,  planning  and  budgeting, 
employee  relations,  acquisition  and 
procurement,  and  internal  paperwork. 
Quality-related  time  includes  inspection, 
rework,  error  prevention,  problem 
determination,  problem  solving,  quality- 
related  maintenance,  and  training. 

■  Process  Cost  (C$T).  Process  cost 
measures  are  concerned  with  the 
consumption  of  resources  allocated  to  the 
process  of  producing  output  products  and 
services  .  Variable  costs  include  supplies 
that  are  used  up  in  producing  outputs  as 
well  as  the  factors  of  production,  which 
include  labor,  machine  hours,  and 
facilities  integral  to  process  operation. 

There  are  also  fixed  process  costs  not 
directly  associated  with  process 
operation  that  must  be  measured, 
managed,  and  controlled  directly.  These 
include  cost  of  excessive  benefits  and 
perquisites,  cost  of  facilities  not  directly 
related  to  work  processes,  and  cost  of 
non-productive  (non-income  producing) 
assets. 

2.1.4  Critical  Success  Factors  (CSFs).  Critical 
success  factors  are  those  primary  process 
performance  measures  that  most  closely  define  and 
track  how  the  process  must  perform  to  be 
considered  successful.  CSFs  are  directly  related  to 
strategic  and  business  plan  objectives  and  goals. 

For  each  critical  success  factor  there  must  be  an 


associated  key  indicator  that  provides  the  measure, 
and  a  standard  of  performance  or  allowable 
variance  from  planned  performance.  The  most 
effective  key  indicators  are  those  designed  into  the 
process  in  such  a  way  as  to  provide  a  readily 
available  or  continuous  reading  of  performance. 
Many  of  the  instruments  on  a  car  dashboard  can  be 
considered  examples  of  key  indicators. 

CSFs  provide  one  means  of  assessing  the  need 
for  process  improvement  actions  or  projects.  This 
is  especially  true  when  the  key  indicator  relates 
directly  to  stakeholder  interests.  For  instance,  if 
customer  satisfaction  survey  results  are  a  key 
indicator  for  a  process  and  the  standard  of 
performance  is  set  at  90%,  any  reading  below  90% 
suggests  the  need  for  corrective  action. 

2.1.5  Total  Systems  Management  (TSM).  Total 
Systems  Management  is  a  means  of  implementing 
process  management  principles.  In  TSM,  every 
process  is  continuously  evaluated  in  terms  of 
satisfying  stakeholder  interests. 

The  TSM  model  is  shown  in  Figure  2-3.  In 
this  model,  the  horizontal  flow  is  called  the  value- 
chain  and  suggests  the  need  for  each  component  of 
a  process  to  add  value  to  the  work  product  moving 
through  the  process.  The  vertical  flow  is  called  the 
control-chain  and  suggests  the  need  for  the  process 
to  conform  to  functional  objectives,  goals,  and 
strategies.  In  many  ways,  these  two  chains  are  in 
dynamic  tension.  One  of  the  responsibilities  of  a 
process  manager  is  to  achieve  the  appropriate 
balance  between  value-chain  objectives  and  control- 
chain  objectives. 

The  four  quadrants  refer  to  areas  of  process 
management  and  improvement  where  stakeholders’ 
interests  intersect.  For  instance,  effectiveness  goals 
for  a  process  must  be  balanced  with  efficiency, 
synchronization,  and  standardization  goals. 
Quadrant  1  (Ql)  measures  require  a  balancing  of 
Customer  interests  with  Higher  Authority  interests. 
Quadrant  2  (Q2)  measures  require  a  balancing  of 
Customer  interests  with  Resource  Provider  interests. 
Likewise,  Supplier  interests  must  be  balanced  with 
the  interests  of  both  Resource  Providers  and  Higher 
Authority  in  Q3  and  Q4  respectively. 


Process  Management  and  Improvement 


2-5 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


i 

r. 

Open  Systems  Quac^ant 

HIGHER 

AUTHORITY 

EfedSveness  Quadrant 

De  facto  S^nctetrcls 

♦ 

Fittiess  for  Purpose 

De  jure  SUtnctards 
(Q4) 

Requirements 
and  Constraints 

Conformance  to 

Standard 

m 

SUPPLIER 

Materials 
and  -► 
Data 

Products 
and  -► 
Services 

CUSTOMER 

1 

N 

+ 

Facilities  and 
Funds 

Effldency  Quacbanft 

Pnx^^Urrra 

(a 

pi  ' ,  ’ 

\V'- 

+ 

RESOURCE 

PROVIDER 

Process  Cast 

(02) 

■ 

- 

-  -►  Value  Chain  -►  ■ 

Figure  2-3  Total  Systems  Management 


As  an  example  of  competing  and  conflicting 
interests,  assume  an  environmental  process. 
Resource  Providers  (citizens)  want  clean  air. 

Higher  Authority  (Congress)  mandates  production 
of  electric  (zero-emission)  automobiles  by  1998. 
Suppliers  (auto  manufacturers)  say  they  can’t  meet 
the  standards  on  time.  Customers  (auto  buyers) 
won’t  buy  an  electric  vehicle  that  doesn’t  perform 
as  well  as  a  gasoline-powered  vehicle.  These  issues 
are  associated  with  all  four  quadrants  in  the  TSM 
model,  and  all  have  to  be  addressed  concurrently  if 
progress  is  to  be  made. 

2.2  Process  Improvement  Principles 

Process  improvement  can  only  take  place  in  an 
enterprise  that  has  adopted  a  process  management 
philosophy.  While  there  are  many  reasons  for  this. 


the  primary  reason  is  that  process  improvement  is 
both  enabled  and  constrained  by  existing  processes, 
organizational  structures,  and  the  installed 
technology  base.  If  these  assets  are  managed 
functionally,  they  cannot  be  effectively  redeployed 
around  a  value-chain  concept,  which  is  the  essence 
of  process  improvement.  In  other  words,  it  is  too 
difficult  to  surmount  functional  barriers  and 
jurisdictional  disputes.  For  process  improvement  to 
be  effective,  the  focus  of  improvement  must  be  on 
the  customer,  not  higher  authority  or  functional 
management. 

2.2.1  Elements  of  Process  Improvement.  An 

enterprise  exists  to  fulfill  a  defined  mission.  If  there 
is  no  mission,  there  is  no  need  for  the  enterprise. 

The  mission  is  fulfilled  by  processes  that  are 
purposefully  designed  around  mission.  If  there  are 
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no  processes,  there  is  no  way  to  fulfill  the  mission. 
A  process  is  defined  as  a  series  of  work  activities 
that  produce  output  products  and  services. 

Activities  take  place  through  the  interactions  of 
people  and  technology.  Without  people  and 
technology,  there  is  no  mechanism  to  operate  the 
activity. 

Process  management  is  overseeing  the  way 
work  activities,  people,  and  technology  combine  to 
produce  useful  outputs.  Performance  measures  are 
used  to  evaluate  process  management  success  with 
respect  to  standards  of  performance.  Performance 
standards  are  derived  from  strategic  and  business 
(or  functional)  objectives  and  goals.  Objectives  and 
goals  are  based  on  the  mission,  enhanced  by 
knowledge  gained,  in  part,  through  research, 
benchmarking,  and  analysis. 

Process  improvement  actions  and  programs 
are  required  when  one  or  more  of  four  conditions 
occur: 

■  The  mission  of  the  organization  changes 
or  is  enhanced. 

■  Customer  needs,  requirements,  or  desires 
change  in  substantial  ways. 

■  Performance  measures  indicate  that 
process  performance  is  consistently 
below  current  standards  of  performance. 

■  Performance  standards  aresignificantly 
raised  to  improve  one  or  more  of  the  four 
categories  of  measures:  conformance  to 
standards,  fitness  for  purpose,  process 
cycle  time,  or  process  cost. 

Process  improvement  actions  and  programs 
are  therefore  not  to  be  undertaken  without  cause  or 
without  consideration  for  all  performance  elements 
process,  people,  and  technology.  Furthermore, 
process  improvement  will  affect  not  only  existing 
processes,  but  also  the  existing  organizational  and 
technological  infrastructure.  In  any  process 
improvement  program,  all  three  elements  must  be 
the  object  of  a  carefully  designed  and  skillfully 
executed  change  management  program. 


2.2.2  Levels  of  Process  Improvement.  There  are 
three  distinct  levels  of  process  improvement,  each 
with  its  own  considerations  and  organizational 
impacts.  In  the  descriptions  below,  as  throughout 
this  guidebook,  the  terms  business  and  functional 
are  interchangeable.  The  term  process  improvement 
is  used  in  this  guidebook  to  encompass  all  three 
levels,  unless  otherwise  indicated. 

■  Continuous  Process  Improvement 

■  Business  Process  Redesign 

■  Business  Process  Reengineering. 

2.2.2.1  Continuous  process  improvement  (CPI). 
Continuous  process  improvement  is  most  closely 
associated  with  the  Total  Quality  Management 
(TQM)  discipline.  The  traditional  approach  is  to 
empower  self-managed  teams  to  make  task-level 
improvements  in  quality,  cycle  time,  and  cost. 
Improvements  are  incremental  and  sustained.  They 
are  creative  responses  to  the  constant  need  to  get  the 
job  done  in  changing  circumstances.  CPI  actions 
typically  are  wholly  contained  within  one  functional 
activity,  although  cross-functional  teams  can  be 
organized  to  deal  with  chronic  or  pervasive 
situations.  To  use  an  analogy,  the  objective  of  a  CPI 
team  is  to  tend  to  one  or  two  trees  in  the  forest. 

2.2.2.2  Business  process  redesign  (BPR).  Process 
redesign  is  the  next  level  of  improvement.  BPR 
actions  are  undertaken  in  a  project  context  with 
planned  or  specific  improvement  objectives.  The 
focus  is  on  streamlining  processes  by  detecting  and 
eliminating  non-value  added  process  time  and  costs, 
and  incorporating  best  practices  in  whole  or  in  part. 
Moderate  improvement  in  quality  with  respect  to 
output  products  and  services  is  usually  one  of  the 
objectives  of  BPR.  Processes  generally  remain 
intact  with  respect  to  other  related  processes,  and 
there  is  little  to  moderate  impact  on  existing 
supporting  information  systems. 

Cross-functional  teams  work  together  to 
model  and  analyze  processes  (AS-IS  condition),  and 
design  a  TO-BE  condition  that  maximizes  process 
operations  within  the  context  of  the  established 
organizational  and  technological  infrastructure. 
There  is  a  strong  reliance  on  capturing  the 
experience  base  of  project  participants  through 
brainstorming  and  other  groupware  techniques  as 
the  basis  for  generating  improvement  ideas.  While 
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these  techniques  often  produce  significant 
improvement  ideas,  the  ideas  are  limited  because  of 
the  insider  perspective  of  members  of  the 
improvement  team.  To  continue  the  analogy,  the 
forest  is  managed  in  spite  of  all  the  trees. 

2.2.2.3  Business  process  reengineering  (BRE). 
Process  reengineering  is  often  undertaken  in 
response  to  dramatic  changes  in  the  external 
environment  (a  paradigm  shift,  for  instance)  that 
apply  considerable  pressure  on  the  ability  of  the 
organization  to  fulfill  its  mission,  improve  its 
competitive  positioning,  or  to  even  survive  as  an 
entity.  BRE  actions  are  radical  and  transforming. 
The  focus  is  on  the  end-to-end  process  or  a 
considerable  subset  of  that  process.  Virtually  all 
functions  within  the  organization  are  affected  by 
BRE  actions.  The  existing  organizational  and 
technological  infrastructures  are  subject  to  major 
dislocations,  and  pressure  is  applied  to  the  very 
culture  of  the  organization. 

BRE  actions  are  initiated  and  guided  by  senior 
leadership.  Cross-functional  teams  are  organized 
and  directed  under  the  auspices  of  a  high-level 
manager.  Because  mission  fulfillment  in  a 
changing  external  environment  is  the  objective,  the 
organization’s  strategic  and  business  plans  are,  or 
should  be,  the  driving  force  behind  BRE  actions. 
The  focus  of  technology  shifts  from  its  role  as 
support  for  current  processes  to  enabler  of  future 
(reengineered)  processes.  The  organization  must 
recreate  itself  around  reengineered  processes. 

All  process  stakeholders  (especially  process 
participants)  are  affected  by  BRE  projects.  New 
performance  measures  must  be  developed  to  reflect 
these  changes.  Assuming  that  the  objective  of  BRE 
is  to  produce  quantum  leaps  in  quality,  cycle  time, 
and  cost  efficiency;  baseline  measurements  and  data 
will  be  of  little  use  (and  may  inhibit)  the  search  for 
new,  more  meaningful  measures.  To  complete  the 
analogy,  the  objective  of  the  BRE  team  is  to  create  a 
new  forest  with  sturdier  and  more  valuable  trees. 

Three  organizational  elements  or  components 
involved  in  process  improvement  at  all  three  levels 
are  process,  people,  and  technology.  At  the  CPI 
level,  people  and  how  they  perform  their  jobs  is  the 
focus.  At  the  BPR  level,  process  is  the  focus  of 


improvement  efforts.  At  the  BRE  level,  technology 
assumes  primary  importance.  But  all  three 
components  are  always  part  of  every  improvement 
effort.  The  differences  are  only  of  degree, 
importance,  and  priority.  We  can  also  make  the 
case  that  each  level  of  improvement  emphasizes 
different  categories  of  measures.  CPI  deals,  to  great 
extent,  with  quality  measures;  BPR  with  cost 
measures;  while  BRE  seeks  to  employ  technology 
to  achieve  significant  breakthroughs  in  process 
cycle  time. 

2.2.3  Barriers  to  Process  Improvement.  Process 
improvement  actions  and  programs  face  obstacles 
that  must  be  identified,  understood,  and  overcome. 
In  general,  the  barriers  fall  into  one  of  three 
categories: 

■  Organizational 

■  Cultural 

■  Regulatory. 

2.2.3.1  Organizational.  These  barriers  are  related 
to  the  hierarchical  stracture  of  the  enterprise  in 
which  employees  focus  more  on  serving 
management  than  on  providing  superlative 
customer  quality  and  service.  Also  included  are  the 
barriers  inherent  in  functional  rather  than  process 
management. 

■  Senior  leadership  commitment  and  buy- 
in:  Business  process  reengineering  is  a 
top-down  initiative  and  depends  upon 
strong  leadership  to  meet  and  overcome 
obstacles  to  success. 

■  Mismatch  between  authority  and 
responsibilities:  Process  improvement 
includes  the  concepts  of  team-based 
performance  and  worker  empowerment, 
both  of  which  challenge  traditional 
management  and  organizational  wisdom. 

■  Functional  and  technical  stovepipes: 

The  concept  of  process  crosses 
established  organizational  boundaries 
and  requires  new  methods  of  managing 
work  products. 
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■  Funding:  Current  funding  practices 
support  the  status  quo  and  inhibit 
management’s  ability  to  apply  scarce 
resources  to  activities  that  produce 
products  and  services  most  needed  by 
internal  and  external  customers. 

2.2.3.2  Cultural.  These  barriers  are  related  to 
work  practices  developed  over  time  that  militate 
against  decentralized  decision  making  and  worker 
empowerment — ^both  requisites  for  high 
performance  in  an  information  age  economy. 

■  Becoming  customer-centered: 

Managers  and  employees  must  shift  from 
a  mle-based  to  a  customer-based  mode 
of  operation  and  establish  performance 
measures  that  focus  on  process  outcomes 
rather  than  process  inputs  such  as  budget. 

■  Aversion  to  job  elimination,  risk,  and 
change:  The  very  essence  of  process 
improvement  is  the  elimination  of  non¬ 
value  added  activities,  radical  change, 
and  adoption  of  high-technology 
solutions  all  of  which  challenge  the 
organizational  status  quo. 

2.2.3.3  Regulatory.  These  barriers  prevent  the 
redesign  of  workflow  commensurate  with  process 
management,  effective  utilization  of  work  teams, 
and  innovative  changes  in  the  recognition  and 
reward  systems  that  promote  effective  teamwork. 

■  Focus  on  current  operations:  Process 
improvement  disrupts  established 
procedure  and  challenges  existing 
regulations  and  directives.  Management 
must  successfully  guide  employees 
through  the  transition  period  from 
existing  process  to  reengineered  process. 

■  Inconsistent  rules,  methods,  and 
techniques  underlying  management 
processes:  Much  of  the  non-value  added 
activities  associated  with  processes 
undergoing  improvement  can  be  traced 
back  to  obsolete  or  inappropriate  rules, 
regulations,  methods,  and  techniques 
whose  worth  must  be  reevaluated. 


■  Policies  on  job  descriptions,  training, 

and  reassignment:  Process  improvement 
calls  for  a  radical  reengineering  of 
personnel  policies  that  currently  limit  the 
authority  of  management  to  develop  a 
flexible,  customer-centered  work  force 
with  appropriate  rewards  and  recognition 
for  team-centered  performance  and 
individual  skill  development. 

2.2.4  Approach  to  Process  Improvement.  The 

methodology  for  conducting  process  improvement 
projects  is  described  in  detail  beginning  in  Section  4 
of  this  guidebook.  This  is  the  general  approach  for 
conducting  a  process  improvement  effort: 

1 .  Understand  the  business  and  functional 
requirements  for  the  process  under  study 
with  respect  to  mission. 

2.  Assess  the  current  status  of  all  process 
elements  (process,  people  and 
technology)  with  respect  to  meeting 
requirements  and  enabling  change. 

3.  Establish  the  baseline  (AS-IS  models) 
with  respect  to  process,  data, 
organization,  and  technology. 

4.  Identify  and  quantify  stakeholder 
interests  in  the  process,  establish  new 
standards  of  performance,  and  design 
measures  and  key  indicators. 

5.  Conduct  an  improvement  analysis 
program  to  identify  potential 
improvement  initiatives  that  will  raise 
process  performance  to  the  desired  level. 

6.  Design  a  change  management  program 
that  will  address  organizational  and 
technical  issues  to  align  improvements  in 
these  elements  with  potential  or  planned 
process  improvement. 

7.  Develop  a  process  vision  and  construct 
TO-BE  models  of  process,  data, 
organization,  and  technology  based  on 
the  vision  and  improvement  initiatives. 
Identify  alternative  means  of  achieving 
the  desired  future  state. 
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8.  Perform  economic  and  risk  analysis  on 
all  alternatives,  and  select  and  document 
a  recommended  course  of  action. 

9.  Perform  enterprise  engineering  to 
construct  an  organizational  and 
technological  platform  suitable  for  the 
improved,  redesigned,  or  reengineered 
process  consistent  with  the  DoD 
Enterprise  Model  and  established 
standards. 

10.  Test  (prototype  or  pilot),  implement, 
deploy,  operate,  and  maintain  the 
improved  process  and  supporting  systems. 

1 1 .  Evaluate  progress,  update  baseline 
models,  and  prepare  for  the  next  cycle  of 
improvements. 

Process  improvement  projects  are  conducted 
by  cross-functional  work  teams  according  to 
established  project  management  principles  with  the 
support  of  project  management  software.  Various 
techniques  are  applied  throughout  the  methodology 
to  gather  and  analyze  process  related  performance 
data;  and  to  display  and  evaluate  potential  changes 
and  improvements.  It  is  important  to  establish  a 
process  owner  to  charter  the  improvement  effort 
and  to  review,  validate,  and  approve  project 
deliverables  and  recommendations. 

2.2.5  Functional  Integration.  Unless  they  are 
very  limited,  processes  frequently  cross  functional 
boundaries.  At  each  functional  boundary  there  is  a 
different  organizational  and  perhaps  different 
technological  infrastructure.  Process  improvement 
projects  must  take  into  account  functional 
differences  in  the  design  of  improved  or 
reengineered  processes.  There  are  three  principle 
approaches  to  accomplishing  functional  integration 
of  improvement  projects: 

1 .  Simplify  cross-functional  organizational 

issues  by  consolidating  functions  or 
remapping  processes  to  functions  to 
reduce  the  number  of  functional  areas 
involved. 


2.  Identify  all  functional  interests  in  a 
proposed  improvement  project,  ensure 
functional  leadership  commitment  to  the 
improvement  project,  and  staff 
improvement  teams  with  representatives 
from  all  involved  functional  units. 

3.  Formalize  the  boundaries  between 
functions  by  establishing  a  supplier/ 
customer  relationship  at  each  junction. 
Treat  these  internal  suppliers  and 
customers  with  the  same  deference  as 
would  be  given  external  suppliers  and 
customers. 

Organizational  change  management  issues  are 
paramount  in  projects  that  cross  functional 
boundaries.  ITie  more  visibility  the  improvement 
project  has  in  the  organization  with  respect  to  level 
of  fonctional  management,  the  more  formidable  the 
change  management  issues.  The  interests  of  the 
higher  authority  stakeholders  (internal  and  external) 
must  be  recognized  and  addressed  in  major 
improvement  projects. 

Technology  issues  are  also  demanding  in 
projects  that  cross  functional  boundaries  where 
existing  technologies  may  be  incompatible. 
Technology  acts  as  both  an  enabler  of,  and  inhibitor 
to,  change — especially  where  the  installed 
technology  base  was  acquired  or  developed  at  great 
time  and  expense. 

In  general,  reengineering  a  major  business 
process  or  subprocess  is  a  non-trivial  exercise 
involving  high-risk,  long  time-frames,  significant 
investment,  project  team  member  turnover,  and 
endless  problems  and  issues  that  have  to  be 
identified  and  resolved.  Success  depends  on  the 
presence  of  a  forceful,  experienced  project  manager 
with  a  written  charter  and  sufficient  authority  to 
execute. 

2.2.6  Migration  and  IVansition  Issues.  The 

installed  information  systems  in  an  organization  are 
termed  legacy  systems  because  they  are  carried 
forward  from  previous  projects.  In  large 
organizations  there  will  be  many  legacy  systems 
performing  essentially  the  same  functions  because 
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they  were  developed  independently  to  support  the 
needs  of  a  single  functional  unit. 

Usually  a  process  redesign  or  reengineering 
project  will  involve  one  or  more  legacy  systems. 
When  this  happens,  one  (or  two)  of  these  legacy 
systems  will  be  designated  as  a  migration  system. 
This  means  that  all  reasonable  efforts  will  be  made 
to  transition  all  systems  support  from  other  legacy 
systems  to  the  designated  migration  system.  The 
old  legacy  systems  will  be  allowed  to  live  out  their 
useful  life  and  be  retired.  The  migration  system 
will  be  enhanced  to  the  extent  possible  to  support 
continuing  process  improvement  requirements. 
Eventually,  a  completely  new  information  system, 
utilizing  advanced  technology,  may  be  authorized  to 
replace  the  migration  system.  Radical  process 
reengineering  normally  requires  completely  new 
information  systems  that  will  support  technologies 
not  present  in,  or  not  adaptable  to,  migration 
systems. 

Once  cross-functional  improvement  projects 
reach  the  transition  phase,  organizational  and 
technological  pressures  peak  as  the  infrastructure 
strains  to  sustain  both  the  existing  process  while 
making  the  transition  to  the  new.  hi  general,  there 
must  be  an  organizational  and  technological  change 
management  plan  in  place  for  both  the  transition 
and  the  deployment  period. 

2.2.7  Information  Systems  Architectures.  The 
purpose  of  having  architectures  is  to  document 
complex,  structural  artifacts  associated  with  the 
following  enterprise  elements: 

■  Information  Architecture  defines 
business  processes  and  shows  their 
relationship  to  organizational  structure. 

■  Functional  Architecture  shows  how 
information  systems  support  business 
process  needs,  or  defines  new 
information  systems  needs. 

■  Data  Architecture  identifies  and  defines 
the  data  entities  that  are  created  or  used 
by  business  processes. 

■  Geotechnical  Architecture  maps  how 
information  systems  components  are 


deployed  to  support  business  process 
needs. 

Architectures  are  developed  or  updated  using  the 
Business  Systems  Planning  (BSP)  technique,  which 
is  performed  following  the  strategic  planning 
process. 

Three  levels  of  architectures  represent 
different  states  of  existence: 

■  Current  baseline  represents  the  present 
state  with  respect  to  all  four 
architectures. 

■  Current  target  documents  an  approved 
set  of  improvements  or  changes. 

■  Objective  documents  the  desired  future 
state  of  the  architectures  following  a 
program  of  changes  and  improvement. 

Architectures  can  help  process  improvement 
teams  understand  the  baseline  condition  of  the 
artifacts  involved  in  the  process  under  study.  Much 
time  and  wasted  effort  can  be  saved  if  these 
resources  are  available  and  used. 

2.3  Department  of  Defense  Initiatives 

Functional  managers  in  the  Department  of 
Defense  are  the  driving  force  in  the  effort  to 
improve  all  major  DoD  business  (functional) 
processes.  The  concept  of  “improved  functional 
process”  includes  any  or  all  of  the  following 
actions: 

■  Realigning  processes  with  changed 
missions 

■  Improving  customer  service 

■  Lowering  costs  of  providing  services 

■  Moving  to  a  “fee-for-service”  mode  of 
operation 

■  Adapting  to  changing  technology  and 
information  systems 

■  Adjusting  processes  in  response  to 
reduced  budgets. 

Managers  face  many  challenges  associated 
with  the  downsizing  of  the  Department  of  Defense. 
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Many  different  but  related  programs,  initiatives,  and 
directives  are  in  place  or  being  developed  to  help 
DoD  managers  achieve  their  objectives.  These 
include  the  following: 

■  Defense  Management  Review  Decisions 
(DMRDs) 

■  Corporate  Information  Management 
(CIM)  Initiative 

■  Management  Control  Program 

■  Total  Quality  Management  (Leadership) 

■  Functional  Process  Improvement 
Program  (FPIP) 


as  the  basis  for  information  system 
implementation. 

■  Provide  common  information  systems 
for  identical  functions. 

■  Develop  information  systems  in 
accordance  with  a  common 
methodology. 

■  Provide  a  shared  communications  and 
computing  infrastructure. 

■  Mandate  common  data  definitions  and 
standards. 

■  Exercise  central  control  over  security. 


■  Life  Cycle  Management  of  Information 
Systems  (LCMIS) 

■  Planning,  Progranuning,  Budgeting 
System  (PPBS). 

One  of  the  purposes  of  this  Framework  is  to 
give  the  functional  manager  a  step-by-step  approach 
(methodology)  that  consolidates  the  principles, 
concepts,  techniques,  and  requirements  expressed  in 
the  programs  listed  above. 

The  Office  of  the  Secretary  of  Defense  (OSD) 
has  expanded  the  focus  of  the  Corporate 
Information  Management  (CIM)  Initiative  and 
Defense  Management  Review  Decisions  (DMRDs) 
to  include  not  only  information  systems  but  alt 
functional  processes  found  within  DoD.  The 
following  subsections  briefly  review  some  of  the 
principles  relevant  to  the  process  improvement 
program. 

2.3.1  Executive  Level  Group  (ELG)  Principles 


2.3.2  Corporate  Information  Management 
(CIM)  Principles.  CIM  may  be  defined  as 
“strategic  business  approach  to  managing 
information  resources.” 

■  The  functional  manager  defines  systems 
requirements,  manages  implementation, 
and  measures  results.  The  Information 
Technology  (IT)  organization  is  a  fee- 
for-service  provider. 

■  The  functional  process  must  be 
simplified  before  it  is  automated. 
Effectiveness  is  gained  and  cost  is 
reduced  by  changing  how  people  work. 
Technology  should  be  applied  only  after 
it  is  certain  that  organizations  can 
implement  the  changes. 

■  Progress  is  increased  and  risk  is  reduced 
when  organizations  proceed  by 
evolutionary  migration  rather  than 
radical  change. 


■  Simplify  functional  processes  before  233  Information  Management  Principles 

(re)designing  related  information 

systems.  ■  Information  will  be  managed  through 

centralized  control  and  decentralized 

■  Apply  economic  analysis  and  execution, 

benchmarking  to  functional  processes. 

■  Simplification  of  processes  by 

■  Require  process  (activity)  models  and  elimination  and  integration  is  preferred 

data  models  for  all  functional  processes 
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over  automation  or  performed  before 
automation. 

■  Existing  and  proposed  processes  will  be 
subject  to  cost/benefit  analysis  that 
includes  benchmarking  against  the  best 
public  and  private  sector  achievements. 

■  Information  systems  performing  the 
same  functions  must  be  common  unless 
specific  analysis  determines  that  they 
should  be  unique. 

■  Functional  managers  shall  be  held 
accountable  for  all  benefits  and  all 
directly  controllable  costs  of  developing 
and  operating  their  information  systems. 

■  Information  systems  shall  be  developed 
and  enhanced  according  to  a 
Department-wide  methodology. 

■  Information  systems  shall  be  developed 
and  enhanced  in  the  context  of  process 
(activity)  models  and  data  models  that 
document  functional  processes. 

■  The  technical  infrastructure  shall  be 
transparent  to  the  information  systems 
that  rely  on  it  (open  systems  and 
standards.) 

■  Common  definitions  and  standards  for 
data  shall  exist  DoD-wide. 

■  Data  must  be  entered  only  once  at  the 
point  of  creation  (source). 

■  Information  must  be  safeguarded  against 
unintentional  or  unauthorized  alteration, 
destraction,  or  disclosure. 

■  All  information  systems  shall  include  a 
“fnendly”  and  consistent  user  interface. 

2.3.4  DoD  Enterprise  Model.  The  DoD 
Enterprise  Model  (described  in  detail  in  other 
documents)  provides  a  framework  or  context  for 
assuring  that  unrelated  process  improvement 
projects  produce  results  that  are  consistent  with  the 


corporate  view  of  processes  and  data  entities.  The 
Enterprise  Model  itself  is  derived  from  the  DoD 
mission  statement.  Project  improvement  teams 
should  validate  all  proposed  process  improvements 
against  the  Enterprise  Model  to  ensure  that  all 
efforts  are  mission  enhancing  and  consistent  with 
strategic  and  business  plans  derived  from  mission. 

The  Enterprise  Model  identifies  thirteen 
functional  processes  that  cross  all  organizational 
boundaries  (mission  areas)  within  DoD.  These 
thirteen  processes  are  organized  into  four  macro 
functional  processes: 

■  Establish  Direction 
—  Establish  Policy 

—  Determine  Requirements 
—  Develop  Plans 
—  Allocate  Resources 

■  Acquire  Assets 

—  Manage  Acquisition 
—  Engineer  (Design  Assets) 

—  Produce  Assets 

■  Provide  CapabUities 

—  Manage  Assets 
—  Develop  Capabilities 
—  Use  Capabilities 

■  Employ  Forces  (Warfighting  Missions)  - 
or-  Serve  Customers  (Support  Missions) 
—  Constitute  Forces 

—  Provide  Operational  Intelligence 
—  Conduct  Operations 

There  are  eight  mission  areas  that  together 
fulfill  all  mission  requirements  in  the  Department: 

■  National  Security 

■  Warfighting  Plans 

■  Command  and  Control 

■  Intelligence 

■  Personnel 

■  Logistics 

■  Finance 

■  Medical 

The  collections  of  data  (entities  and  subject 
data  bases)  that  support  the  processes  and  mission 
areas  are  comprised  of  the  following: 
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■  Concepts 

—  World  Situation 
—  Guidance 
—  Agreements 
—  Plans 
—  Organizations 
—  Capabilities 
—  Location 

■  Assets 

—  People 
—  Materiel 
—  Facilities 
—  Funds 
—  Real  Estate 

A  process  improvement  project  will  be 
associated  with  one  or  more  mission  areas,  macro 
processes,  and  data  entities  documented  in  the 
Enterprise  Model.  Eventually,  automated 
information  systems  will  be  developed  to  operate  on 
open-systems  platforms,  have  appropriate  access  to 
a  DoD-wide  corporate  data  base,  and  support  all 
DoD  process  requirements.  All  process 
improvement  projects  within  DoD  should  include 
this  vision  in  the  statement  of  principles  that  guide 
improvement  efforts. 

The  Enterprise  Model  will  be  contained  within 
the  Defense  Data  Repository  System  (DDRS), 
which  will  be  available  to  all  process  improvement 
teams  to  help  guide  process  improvement  efforts. 

2.4  Guidance  and  Directives 

The  process  improvement  program  is 
authorized  by  the  following  DoD  official 
documents: 

■  DoD  8000.1  Directive:  Defense 
Information  Management  Program 

■  DoD  8020.1  Instruction:  Functional 
Process  Improvement 

■  DoD  8020.1 -M  Procedure:  Interim 
Management  Guidance  on  Functional 
Process  Improvement. 


2.5  Roles  and  Responsibilities 

The  specific  duties  and  responsibilities  of 
DoD  elements  with  respect  to  process  improvement 
are  contained  within  the  documents  listed  in  the 
subsection  above.  The  following  highlights  are 
intended  to  summarize  those  concepts. 

2.5.1  Principal  Staff  Assistant  (PSA) 

■  Exercise  final  Department- wide 
responsibility,  authority,  and 
accountability  for  all  process 
improvements  within  the  functional  area 

■  Ensure  that  Defense  Information 
Management  program  requirements  for 
functional  process  improvement  are 
implemented  and  executed  and  that  they 
comply  with  relevant  standards 

■  Assign  functional  managers  to  perform 
process  improvement  activities  on  their 
behalf 

■  Establish  internal  procedures  supporting 
the  process  improvement  methodology 

■  Review  and  approve  process 
improvement  deliverables 

■  Develop  PPBS  requirements  for  process 
improvement  and  information  systems 
development 

■  Act  as  the  functional  proponent  for  all 
information  systems  within  the 
fimctional  area  and  comply  with  LCMIS 
requirements. 

2.5.2  Functional  Information  Manager  (FIM) 

■  Guide  development  of  the  DoD 
Enterprise  Model  to  provide  the 
managerial  framework  necessary  for 
determining  the  relationships  among 
functional  areas  and  activities. 
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■  Facilitate  coordination  of  data 
requirements  across  functional  areas  of 
the  Department 

■  Support  PSAs  and  functional  managers 
in  the  development  of  goals  and 
objectives  and  facilitate  resolution  of 
cross-functional  issues 

■  Receive  and  review  corporate 
Information  Management  (IM)  central 
fund  requirements  developed  by 
functional  managers 

■  Chair  working  groups  related  to  cross¬ 
functional  and  implementation  issues 

■  Provide  the  linkage  between  PSAs  and 
the  support  services  available  from  the 
Defense  Information  Systems  Agency 
(DISA) 

■  Maintain  current  information  related  to 
public,  private,  and  academic  sector 
achievements  in  process  improvement  to 
facilitate  benchmarking  and  best 
practices  studies. 

2.5.3  Technical  Integration  Manager  (TIM) 

■  Advocate  Information  Management  (IM) 
migration  solutions  related  to  functional 
process  improvement  actions 

■  Prototype  and  test  information  system 
components  related  to  process 
improvement 

■  Perform  configuration  management 
functions 

■  Assist  in  the  development  of  Technical 
Management  Plans  (TMPs)  which  are 
incorporated  into  Functional  Economic 
Analyses  (FEAs) 

■  Review  TMPs  for  conformance  to 
standard  architectures 


■  Provide  transition  strategies  for 
migrating  from  baseline  and  migration 
systems  to  an  open  systems  environment 

■  Assist  functional  managers  in  the 
preparation  of  an  appropriate  information 
system  strategy  that  supports  functional 
objectives. 

2.5.4  Functional  Data  Administrator  (FDAd) 

■  Develop  the  data  management  and 
information  system  strategy  for  each 
functional  activity 

■  Serve  as  the  advisor  and  reviewer  of  data 
models  developed  by  or  for  the 
functional  manger  to  ensure 
conformance  to  established  standards 
and  architectures 

■  Integrate  data  models  across  functional 
activities  and  assist  in  reconciling 
activity  models  with  integrated  data 
models 

■  Use  approved  data  models  as  a  primary 
source  for  standard  data 

■  Support  functional  managers  in  the 
development  of  Data  Management  Plans 
(DMPs)  which  are  included  in  the  FEAs. 

2.5.5  Functional  Manner 

■  Execute  the  Defense  Information 
Management  functional  management 
process  within  the  functional  activity  or 
activities  specified  by  the  PSA 

■  Program  budget  and  execution  funds 
required  to  implement  the  Defense 
Information  Management  program 
within  their  functional  activity 

■  Manage  the  implementation  of  process, 
data,  and  information  system  changes 
approved  by  the  PSA 

■  Participate  in  working  groups  associated 
with  process  improvement. 
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2.5.6  Process  Manager 

■  Act  as  the  representative  for  all 
functional  managers  involved  in  a 
process  management  or  process 
improvement  action  or  project 

■  Establish  objectives,  goals,  and  strategies 
for  process  improvement  projects 

■  Establish  critical  success  factors, 
performance  measures,  and  key 
indicators  for  process  management  and 
process  improvement  actions  and 
projects 

■  Assist  in  staffing  cross-functional 
process  improvement  teams  and 
providing  access  to  functional  and 
process  subject  matter  experts 

■  Review  and  approve  all  improvement 
project  in-process  deliverables 

■  Assume  a  lead  role  in  organizational 
change  management  issues  and 
recommendations. 


2.5.7  Project  Manager 

■  Assume  responsibility  for  planning  and 
executing  project  improvement  projects 

■  Establish  and  track  project  schedules, 
milestones,  and  budgets 

■  Ensure  that  process  improvement 
projects  are  conducted  in  accordance 
with  all  policy  and  guidance  according  to 
the  process  improvement  methodology 

■  Identify  and  resolve  project  related 
problems  and  issues 

■  Lead  process  improvement  workshops, 
interviews,  surveys,  and  benchmarking 
activities 

■  Prepare  and  submit  all  process 
improvement  in-process  deliverables 

■  Ensure  open  communications  among  all 
interested  parties  with  respect  to  project 
performance 

■  Prepare  and  submit  regular  project  status 
reports. 
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SECTION  3.  FRAMEWORK  FOR  MANAGING  PROCESS  IMPROVEMENT 


Business  process  improvement  (especially 
process  reengineering)  is  a  complex  undertaking 
that  demands  leadership  from  the  highest  levels  of 
the  Department  of  Defense  and  participation  from 
virtually  all  executives,  managers,  and  professional 
employees.  Davenport'*  posits  five  elements  that 
together  provide  the  techniques  and  tools  to  support 
the  concept  of  process  reengineering: 

1 .  Total  Quality  Management  (TQM) 
principles  and  practices  ensure  high- 
quality  products  and  services  to  both 
internal  and  external  customers  of 
business  processes. 

2.  Industrial  engineering  provides  process 
measures,  controls  on  process  efficiency 
and  effectiveness,  and  standardized 
procedures. 

3.  Workflow  design  that  incorporates  the 
concurrent  management  of  technological 
and  human  change. 

4.  Process  redesign  incorporates 
innovations  and  eliminates  non-value 
added  time  and  costs  from  processes. 

5.  The  introduction  of  competitive 
(aggressive)  information  technology 
enables  superlative  customer  quality  and 
service. 

The  concept  of  an  end-to-end  process 
improvement  model  with  a  supporting  methodology 
seems  to  be  the  most  expeditious  way  to  implement 
Davenport’s  principles.  Such  a  methodology 
would: 

■  Begin  with  a  statement  of  mission, 
vision,  objectives,  goals,  and  strategies 

■  Produce  a  reengineered  business  process 
to  support  the  stated  organizational 
mission  and  related  strategic  and 
business  plans 


■  Continue  through  information  systems 
design,  deployment,  and  operations 
consistent  with  the  Enterprise  Model 

■  Employ  process  management  principles 
to  ensure  that  process  improvement  gains 
are  held 

■  Focus  on  cultural  and  organizational 
change  management  issues  and  structural 
barriers  to  change  that  represent  the  most 
risk-prone  component  of  process 
improvement  efforts. 

The  Framework  for  Managing  Process 
Improvement  (Framework  or  F/MPI)  is  designed  to 
enable  process  improvement  efforts  within  the 
Department  of  Defense  consistent  with  the 
established  body  of  expertise  for  process 
improvement  and  best  practices  analysis. 

3.1  Process  Improvement  Model 

Figure  3-1  illustrates  the  process  improvement 
model  supported  by  the  Framework.  The  model 
shows  that  process  improvement  proceeds  from  an 
understanding  of  the  current  situation  represented 
by  these  blocks  in  the  figure: 

■  The  current  environment  (A)  is  external 
to  processes  under  consideration  and 
represents  all  factors  outside  of  the  direct 
control  of  processes  that  can  influence  or 
constrain  process  improvement  efforts. 

■  The  current  organizational  infrastructure 
(B)  supports  the  existing  process.  The 
relationship  of  the  process  to  the  existing 
organizational  structure  must  be  well- 
understood  so  that  appropriate 
organizational  changes  can  be  made  in 
light  of  planned  process  improvements. 


4  Process  Innovation,  Thomas  H.  Davenport,  HBS  Press,  1993. 
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Figure  3-1.  Framework  for  Managing  Process  Improvement 


■  The  current  technological  infrastructure 
(C)  provides  a  platform  of  information 
management  and  communications 
services  for  existing  processes.  The 
relationship  of  processes  to  platforms 
must  be  well-understood  so  that 
appropriate  technological  changes  can  be 
made  in  light  of  planned  process 
improvements  without  unduly  affecting 
existing  information  systems. 

Blocks  numbered  1  through  4  show  the  major 
phases  performed  in  the  process  improvement 
methodology.  These  activities  lead  to  a 
reengineered  process  and  the  necessary  changes  in 
the  organizational  and  technological  infrastructure 
needed  to  support  the  reengineered  process. 

3.1.1  Planning  Phase  (1).  Planning  activities 
analyze  the  current  process  baseline  with  respect  to 
the  external  environment  and  the  organizational  and 
technological  infrastructure  to  develop  a  vision  for  a 
future  state  that  defines  where  the  organization 


wants  to  be  and  how  to  get  there.  This  vision  is 
expressed  in  a  series  of  models  and  architectures 
that  define  the  organization,  processes,  information 
resources,  and  technology  enablers  and  is  consistent 
with  the  DoD  Enterprise  Model. 

3.12  Process  Reengineering  Phase  (2A).  Process 
reengineering  activities  consider  planning  outputs, 
technology  enablers,  and  stakeholder  requirements 
to  design  improved  processes  that  advance  the 
organization  toward  its  planned  future  state. 
Reengineering  seeks  to  make  processes 
dramatically  more  effective  and  efficient.  These 
activities  also  provide  inputs  to  the  change 
management  program,  which  conditions  the 
organization  for  the  coming  enhanced  processes. 

3.13  Organizational  Change  Management 
Phase  (2B).  Organizational  change  management 
program  activities  define  a  series  of  cultural, 
organizational,  and  personnel-related  changes 
necessary  to  remove  barriers  to  change  and 
maximize  the  potential  of  improved  or  reengineered 
processes. 
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3.1.4  Technical  Change  Management  Phase 

(2C).  Technical  change  management  program 
activities  ensure  that  the  technology  changes  needed 
to  support  reengineered  processes  are  consistent 
with  the  DoD-wide  technology  platform  and  the 
DoD  Enterprise  Model.  Technology  improvement 
program  activities  are  also  concerned  with  such 
issues  as  legacy  systems,  migration  systems,  and 
systems  integration. 

3.1.5  Enterprise  Engineering  Phase  (3). 

Enterprise  engineering  activities  provide  the 
hardware,  communications,  software,  and  data  base 
structures  needed  to  support  the  reengineered 
process.  These  activities  also  provide  inputs  to  both 
change  management  phases  (2B  and  2C)  to  help 
ensure  that  all  elements  of  process  improvement — 
process,  people,  and  technology — are  designed  to 
be  mutually  supporting.  Enterprise  engineering 
activities  conclude  with  pilot  implementation  or 
prototyping  services  for  the  redesigned  process. 

3.1.6  Project  Execution  Phase  (4).  Project 
execution  activities  bring  together  the  planned 
process,  organizational,  and  technology  changes 
under  a  project  management  concept  to  provide  a 
coherent  and  manageable  means  of  incorporating  all 
design  changes  into  the  existing  internal 
environment  (organization,  technology  and 
process).  Project  execution  activities  include 
implementation,  deployment,  operations, 
maintenance,  and  continuing  process  improvement. 

All  of  the  activities  in  the  four  mainline  phases 
(planning,  process  reengineering,  enterprise 
engineering,  and  project  execution)  and  the 
supporting  phases  (organizational  change 
management  and  technology  improvement) 
ultimately  result  in  a  new  level  of  performance  for 
the  organization. 

It  is  important  to  note  that  the  successful 
implementation  of  all  the  six  phases  of  the  process 
improvement  methodology  requires  leadership  and 
active  participation  from  executives,  managers,  and 
professional  employees  serving  in  the  process; 
effective  coordination  by  the  designated  process  and 
project  manager;  and  access  to  support  services 
provided  under  the  CIM  program. 


3.2  The  Business  Engineering  Management 

Model 

Figure  3-2  reorganizes  the  Framework 
methodology  into  a  format  that  illustrates  the 
management  processes  supporting  the  methodology. 
This  format  emphases  how  management  decisions 
flow  from  phase  to  phase  as  the  inputs  shown  on  the 
left  of  the  process  box  are  transformed  into  the 
outputs  displayed  on  the  right. 

Change  management  is  shown  in  the  center  of 
the  model  to  reinforce  its  critical  importance  in  the 
success  of  the  other  phases.  Ultimately,  nothing  can 
happen  until  and  unless  the  organization,  its 
managers,  and  its  employees  understand  and 
support  improvement  efforts.  The  arrows 
emphasize  the  reiterative  nature  of  process 
improvement  efforts  and  the  interactions  that  take 
place  between  the  phases. 

Each  of  the  inputs  to  the  model  is  transformed 
dramatically,  often  radically,  by  the  improvement 
process. 

Current  business  processes  are  improved 
incrementally,  redesigned  to  maximize  efficiency,  or 
reengineered  to  achieved  maximum  effectiveness. 
Funding  is  eventually  transformed  from  a  constraint 
(negative  presumption)  on  process  performance  into 
an  enabler  (positive  presumption)  of  superior 
oiganizational  performance.  What  is  meant  by  this 
is  that  waste  and  non- value  added  activities  are 
reduced  along  with  the  debilitating  effects  they  have 
on  process  performance  and  employee  satisfaction. 

Existing  technology  is  modernized  into 
effective  enablers  of  further  process  improvement 
performance  in  pursuit  of  information  age  values. 
Underutilized  assets  are  redeployed  to  processes 
that  demonstrate  superior  customer-centered 
performance.  The  organizational  structure  itself, 
and  associated  management  and  employee 
practices,  are  transformed  into  effective  resources  in 
support  of  process  management  principles. 
Teamworic,  empowerment,  enriched  job 
responsibilities,  skill-based  recognition  and  reward 
systems,  continual  training,  and  employee 
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resourcefulness  are  the  eventual  outcomes  that 
produce  a  high-performance,  satisfying  work  place. 

3.3  The  Framework  Support  Matrix 

Figure  3-3  illustrates  the  framework  support 
concept  that  shows  the  resources  provided  by  the 
methodology  to  support  process  improvement 
efforts.  The  performance  line  indicates  that  the 
methodology  consists  of  a  series  of  phases,  steps, 
and  tasks  that  produce  one  or  more  deliverables. 
There  are  a  total  of  six  phases  and  25  steps  in  the 
methodology.  Each  step  consists  of  several  tasks 
that  produce  the  required  deliverables.  The  support 
matrix  shows  the  materials  and  services  that  are 


provided  to  enable  all  actions  in  the  performance 
line. 

■  Project  Management  Guidebook  and 
Software  Support  System.  Materials 
suitable  for  organizing  and  managing  a 
process  improvement  project  include  pro 
forma  work  breakdown  structures, 
schedules,  milestones,  and  resource 
allocation  matrices  in  machine-readable 
form. 

■  Framework  Methodology  Guidebook 

(this  guidebook). 
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■  General  Briefing  Documents  and 
Presentation  Aids.  A  series  of  briefing 
packages  and  presentation  aids  suitable 
for  m^ing  presentations  about  process 
improvement  and  the  methodology  for 
process  improvement. 

■  Phasedevel  Briefings.  A  series  of  six 
briefing  packages,  one  for  each  phase  of 
the  methodology,  suitable  for  use  with 
process  and  functional  managers  and 
process  improvement  teams. 

■  Step-level  Abstracts.  A  series  of  25 
one-page  summaries  relating  to  all 
activities,  techniques,  deliverables,  and 
support  services  for  each  step  in  the 
methodology,  which  can  be  used  as  a 
quick  reference  for  all  step  requirements. 

■  Deliverable  Templates.  Templates 
illustrating  the  requirements  for  each 
deliverable  produced  in  the  conduct  of 
process  improvement  projects. 

■  Phase-level  Assessments.  A  series  of 
six  assessment  instruments  that  evaluate 


the  organization’s  readiness  for  process 
improvement  in  terms  of  process,  people, 
and  technology  prior  to  the 
commencement  of  each  phase. 

■  Checklists.  A  series  of  checklists  related 
to  the  activities  that  must  be  completed 
for  each  step  and  task  in  the 
methodology  as  well  as  the  minimum 
requirements  for  each  deliverable 
produced  by  the  methodology. 

■  Phase-level  Thtorials.  A  series  of  six 
tutorials,  one  for  each  methodology 
phase,  that  review  the  principles  and 
concepts  of  each  phase. 

■  Phase-level  Evaluations.  A  series  of  six 
evaluation  forms  used  to  rate  the  degree 
of  success  achieved  at  the  completion  of 
each  phase. 

■  Techniques  and  Tools.  A  series  of 
primers  on  each  of  the  techniques  and 
tools  used  in  process  improvement 
projects  showing  their  purpose,  how  and 
when  to  use  them,  and  the  results  that 
can  be  expected. 
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■  Workshops.  A  series  of  structured  ■  Guidebooks.  A  series  of  documents 

workshops  supporting  process  related  to  major  improvement 

improvement  project  efforts  at  points  in  deliverables. 

the  methodology  that  benefit  most  from 

group  activity.  ®  Support  Aids  and  Services.  R.esources 

for  process  improvement  teams. 

■  Training  Courses.  A  curricula  of 
process  improvement-related  training 
courses. 
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SECTION  4.  PHASE  1:  STRATEGIC  AND  BUSINESS  PLANNING 


Process  improvement  begins  with  planning. 
Planning  provides  the  context  for  developing  a 
process  vision,  which  is  the  fundamental  driver  of 
all  improvement  efforts.  The  more  radical  the 
improvement  objective,  the  more  important  it  is  to 
associate  process  improvement  efforts  with  strategic 
and  business  objectives  and  goals.  Planning  also 
determines  the  measures  and  critical  success  factors 
that  will  be  used  to  evaluate  the  success  of 
improvement  projects.  Planning  defines  the 
destination,  while  the  process  improvement  project 
provides  the  vehicle.  There  is  much  trath  in  the 
aphorism  that  if  you  don’t  know  where  you  are 
going,  any  road  will  get  you  there. 

Process  innovation  is  meaningful  only  if  it 
improves  a  business  in  ways  that  are 
consistent  with  its  strategy.  In  fact,  process 
innovation  is  impossible — or  at  least  only 
accidental — unless  the  lens  of  process 
analysis  is  focused  on  a  particularly  strategic 
part  of  the  business,  with  particular  strategic 
objectives  in  mind.’ 

There  are  two  levels  of  planning;  strategic  and 
business  (or  annual)  planning.  Strategic  planning 
looks  outward  to  establish  the  context  in  which  the 
organization  or  business  unit  will  operate  with 
respect  to  its  defined  mission,  and  to  set  the  vision 
for  a  desired  future  state.  Business  planning  looks 
inward  to  marshal  available  resources  in  pursuit  of 
the  vision.  Both  levels  of  plaiming  rely  on 
definitive  objectives  and  quantitative  measures  of 
performance  to  guide  and  monitor  progress. 

There  are  five  steps  in  the  planning  phase: 

■  Develop  or  validate  the  strategic  plan 

■  Develop  or  validate  the  business 
systems  plan 

■  Develop  or  validate  the  annual 
business  plan 

■  Construct  performance  cells 
(performance  measures)  for  processes 

■  Establish  the  process  improvement 
project. 


At  the  completion  of  the  planning  phase,  a 
process  improvement  project  is  in  place  that  is 
consistent  with  the  strategic  objectives  of  the 
enterprise,  supported  by  sufficient  resources,  guided 
by  a  well-conceived  process  vision,  and  bounded  by 
clearly  defined  objectives.  The  objectives  are 
related  to  quantified  goals  that  define  the  success 
factors  for  the  project,  and  keyed  to  performance 
measures  that  monitor  the  attainment  of  project 
objectives. 

The  principal  benefit  of  the  planning  phase  is 
that  improvement  teams  begin  their  work  with  a 
clear  understanding  of  their  mission  and  an  idea  of 
what  successful  performance  will  look  like.  Their 
efforts  are  properly  focused  on  how  they  will 
achieve  the  process  vision  and  performance 
objectives  set  in  place  by  senior  management,  not 
wasted  on  trying  to  determine  what  their  objectives 
should  be. 

The  planning  phase  of  the  Framework  for 
Managing  Process  Improvement  is  supported,  in 
part,  by  the  following  resources: 

■  F/MPI  Management  Briefing  on 
Planning 

■  F/MPI  Planning  Assessment 

■  F/MPI  Planning  Tutorial 

■  F/MPI  Performance  Cell  Tutorial 

■  F/MPI  Planning  Evaluation  Worksheet 

■  Process  Improvement  Scoping  Workshop 

■  Preparing  For  and  Initiating  Functional 
Process  Lnprovement  (FPI)  Programs 
Guidebook. 

The  techniques  (described  in  Section  10)  most 
useful  in  this  phase  include  the  following: 


5  Davenport,  page  117. 
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■  Brainstorming 

■  Nominal  Group  Technique 

■  Performance  Cell  Technique 

■  Strategic  Benchmarking 

■  Quality  Function  Deployment 

■  SWOT  Analysis 

■  Hoshin  Planning 

■  Process  Flow/Process  Deployment 
Diagraming. 

4.1  Step  1:  DevelopA^alidate  the  Strategic  Plan 

While  not  every  organizational  unit  (business 
unit)  is  required  to  develop  a  strategic  plan,  every 
unit  is  governed  by  a  strategic  plan.  Subordinate 
strategic  plans  should  always  be  a  subset  of  higher 
authority  strategic  plans.  In  general,  the  lowest 
organizational  level  requiring  a  strategic  plan  is  the 
business  unit  or  functional  area.  Below  this  point, 
annual  business  planning  is  sufficient. 


the  external  boundaries  of  the  enterprise  with 
respect  to  the  environment  in  which  it  operates. 

The  external  environment  is  comprised  of  several 
factors  as  shown  in  Figure  4-1: 

■  Socio-economic 

■  Geopolitical 

■  Technological 

■  Markets  and  Competition. 

The  strategic  plan  is  developed  by  considering 
the  interrelationships  of  mission,  customer  base 
requirements,  and  environment  with  respect  to 
potential  organizational  performance.  When  there 
is  a  gap  between  present  and  potential  performance, 
an  improvement  effort  may  be  required  to  close  the 
gap.  The  requirements  of  the  improvement  effort 
are  expressed  in  terms  of  breakthrough  objectives. 
The  strategic  plan  indicates  the  dimensions  of  the 
improvement  project,  not  the  means. 


The  strategic  plan  defines  what  an 
organization  is  all  about  (mission  and  vision), 
whom  it  will  serve  (customers  and  other 
stakeholders),  what  needs  it  will  fulfill  (products 
and  services),  how  well  it  will  perform  (objectives 
and  goals),  and  under  what  terms  it  will  operate 
(values  and  beliefs).  Strategic  planning  establishes 


Most  strategic  planning  requirements  call  for  a 
minimum  planning  horizon  of  three  to  five  years, 
although  ten  years  is  not  uncommon.  Considering 
that  radical  reengineering  projects  may  take  two  to 
three  years  to  complete,  and  the  life  cycle  of  the 
improved  process  is  five  to  seven  years,  it  is  clear 
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that  the  strategic  plan  should  be  long-range  in 
nature.  Of  course,  strategic  plans  must  be  revisited 
and  updated  every  year  to  capture  changes  in 
mission,  customer  requirements,  and  the  external 
environment. 

The  principal  deliverable  in  the  strategic 
planning  step  is  the  strategic  plan  itself.  This  step  is 
considered  complete  once  the  strategic  plan  has 
been  reviewed  and  approved  by  higher  authority. 
The  F/MPI  Abstract  for  Step  1  provides  a  complete 
overview  of  the  characteristics  of  the  step  in  the 
methodology.  The  F/MPI  Planning  Tutorial 
contains  a  complete  description  of  the  contents  of 
the  strategic  plan. 

The  following  tasks  are  performed  in  the 
strategic  planning  step: 

■  Develop/validate  the  organizational 
articles  of  faith. 

■  Identify  major  customer  groupings  and 
general  customer  requirements. 

■  Conduct  strategic  benchmarking  to 
establish  performance  targets. 

■  Conduct  SWOT  analysis 

■  Identify  core  competencies. 

■  Determine  high-level  customer  service 
requirements. 

■  Prepare  breakthrough  objectives. 

■  Identify  performance  measures. 

■  Document  the  strategic  plan. 

■  Review  and  approve  the  strategic  plan. 

4.1.1  Develop/Validate  Mission,  Vision 
Statement,  Values,  and  Beliefs.  Every 
organizational  unit  must  be  guided  by  a  mission 
statement  that  defines  why  the  organization  exists, 
and  what  it  must  do  to  justify  its  existence. 
Everyone  must  understand  the  mission  because  it  is 
the  basis  for  decision  making  within  the 
organization. 

Every  organization  should  have  a  vision 
statement.  Vision  is  the  framework  that  guides 
those  choices  that  determine  the  nature  and 
direction  of  an  organization.  It  is  what  an 
organization  wants  to  be.^  Every  decision  and 


every  action  taken  in  the  organization  supports 
either  the  mission  or  the  vision,  or  they  are 
irrelevant. 

Mission  and  vision  are  organizational 
attributes.  An  organization  must  also  have  a  written 
statement  of  values  and  beliefs  that  are  cultural 
attributes.  Values  and  beliefs  govern  conduct.  They 
establish  the  ethical  and  moral  basis  for  all  decision 
making  within  the  organization.  They  define  the 
lines  that  managers  and  employees  will  not  cross  in 
times  of  adversity.  Caution:  do  not  articulate 
values  and  beliefs  that  cannot  or  will  not  stand  in 
the  face  of  adversity. 

Along  with  the  process  vision  and 
improvement  objectives  (to  be  discussed  later),  this 
task  establishes  a  foundation  for  all  process 
improvement  efforts.  Process  improvement  efforts 
must  support  mission,  be  guided  by  vision,  and 
sustain  values  and  beliefs. 

This  task  is  usually  performed  in  a  facilitated 
workshop  setting  by  senior  level  executives  using 
brainstorming  and  nominal  group  techniques.  The 
final  deliverable  should  be  expressed  in  one  page  of 
text — at  most,  two.  Every  process  improvement 
workshop  and  activity  thereafter  should  begin  with 
a  reaffirmation  of  these  principles. 

4.1.2  Identify  Major  Customer  Groupings.  The 

next  task  is  to  identify  and  categorize  the  customer 
groupings  that  the  organizational  unit  serves  or 
intends  to  serve.  While  the  interests  of  all 
stakeholders  in  the  organization  must  be  accounted 
for,  the  starting  point  is  to  determine  who  the 
customers  are.  Without  a  clear  understanding  of 
customers  and  their  general  needs,  no  other 
stakeholder  interests  can  be  served. 

Like  mission  and  vision,  a  knowledge  of 
customers  is  fundamental  to  decision  matong  within 
the  organization.  Every  decision  either  serves 
customer  interests  in  some  way,  directly  or 
indirectly,  or  it  is  irrelevant.  Customer 
identification  is  also  the  starting  point  for  process 
improvement  efforts.  Without  a  customer  focus, 
process  improvement  efforts  are  destined  to  be 
futile. 


6  Vision  in  Action,  Benjamin  B.  Tregoe,  et  al.,  Simon  &  Schuster,  1989. 
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in  the  business  unit  writing  the  strategic  plan  is  a 
full  participant  in  the  benchmarking  program. 


The  more  that  is  known  about  customers, 
individually  or  as  groups,  the  more  effective  will  be 
the  organization’s  strategic  planning  and, 
eventually,  process  improvement  efforts.  In  private- 
sector  enterprises,  technology  is  making  it  possible 
to  evaluate  and  understand  individual  customer 
needs,  and  customize  services  to  fit  those  individual 
needs.  In  public-sector  enterprises,  this  level  of 
precision  is  neither  practical  nor  necessary. 

This  task  is  usually  performed  in  a  workshop 
setting  by  functional  managers  who  are  supported 
by  research,  surveys,  questionnaires,  and  interview 
results.  The  specific  data  collected  on  customer 
groups  depends  heavily  on  the  mission  of  the 
organizational  unit  and  the  nature  of  the  products 
and  services  it  produces.  However,  there  should  be 
a  defined  purpose  for  every  item  of  data  collected. 

4.1.3  Conduct  Strategic  Benchmarking. 

Strategic  benchmarking  is  now  a  fundamental 
component  of  strategic  planning  and  is  absolutely 
necessary  for  the  task  of  constructing  a  process 
vision.  Strategic  benchmarking  is  the  basis  for 
setting  performance  targets  for  processes  based  on 
discovering  what  other  organizations  with  like 
processes,  products  or  services,  and  similar 
customer  constituencies  have  done. 

Strategic  benchmarking  provides  a  breath  of 
fresh  air  to  counteract  the  stagnation  of  only  looking 
within  the  organization  for  process  improvement 
ideas  and  performance  targets.  It  is  quite  possible 
that  the  results  of  strategic  benchmarking  may 
indicate  a  need  to  revisit  the  organization’s  vision 
statement,  which  may  look  puny  when  compared  to 
what  others  are  accomplishing  at  present. 

The  technique  of  strategic  benchmarking  is 
well  documented  in  the  literature.  A  complete  and 
rewarding  strategic  benchmarking  program  will 
take  from  three  to  six  months  to  complete,  although 
it  can  be  done  in  parallel  with  other  methodology 
tasks  and  steps.  Strategic  benchmarking  is  usually 
done  on  a  peer-to-peer  basis  meaning  that  the  senior 
executives  in  the  benchmarking  organization  meet 
with  senior  executives  in  the  target  organizations; 
and  junior  managers  with  junior  managers.  The 
best  results  are  obtained  when  the  senior  executive 


The  final  outcome  of  a  strategic  benchmark 
program  is  a  full  report  of  the  objectives  of  the 
benchmark,  the  results  obtained,  and  the  analysis  of 
those  results.  A  typical  benchmark  report  will  be 
from  25  to  50  pages.  It  should  be  provided  as  input 
to  process  improvement  teams. 

4.1.4  Conduct  StrengthAYeakness/Opportunity/ 
Threat  (SWOT)  Analysis.  Once  an  organization 
has  articulated  it  mission,  vision,  values,  and 
beliefs,  understands  who  its  customers  are  and  their 
general  needs,  and  has  looked  outward  for  ideas  and 
inspiration,  it  is  ready  to  analyze  its  situation  with 
respect  to  the  environment  in  which  it  operates. 

This  is  called  a  SWOT  analysis,  which  is  the 
acronym  for  the  areas  that  are  studied.  The  results 
of  the  analysis  are  used  to  develop  breakthrough 
objectives  in  the  strategic  plan,  business  plans,  and 
process  improvement  plans.  Combined  with  the 
results  of  strategic  benchmarking,  this  analysis  is  all 
that  is  required  to  establish  process  performance 
gaps,  which,  along  with  peif^ormance  measures,  are 
the  essential  input  to  process  improvement  projects. 

SWOT  analysis  is  usually  performed  in  a 
workshop  environment  by  functional  managers 
assisted  by  staff  analysts  who  have  collected 
meaningful  data  on  environmental  factors,  statistics, 
and  measures.  Strengths  and  weaknesses  supply  the 
basis  for  understanding  how  the  organization  can 
best  respond  to  probable  or  potential  opportunity 
and  threat  factors  that  exist  in  the  external 
environment.  Long  a  mainstay  in  military  planning, 
SWOT  is  equally  valuable  as  a  planning  technique 
for  business-type  processes.  While  the  geopolitical 
factor  is  most  important  in  military  planning,  the 
technical  factor  is  often  the  most  critical  in  non¬ 


4.1.5  Identify  Core  Competencies.  Core 
competencies  are  those  things  that  the  organization 
does  best:  they  are  in  a  sense  the  capabilities  that 
define  the  organization.  Core  competencies  directly 
relate  to  mission  and  customer  service  and  are  those 
processes  and  functions  which  could  not  be 
realistically  outsourced  without  substantially 


military  planning 
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weakening  the  organization.  SWOT  analysis 
combined  with  strategic  benchmarking  helps  to 
crystalize  just  which  functions  and  processes  make 
up  the  core  business. 

Recognizing  and  defining  core  competencies 
are  crucial  because  process  improvement  efforts 
should  focus  on  them  first  and  foremost.  If  the  core 
competency  of  an  organization  is  outbound 
logistics,  that  should  be  the  focus  of  process 
redesign  and  process  reengineering  efforts.  Other 
supporting  processes  should  be  subject  only  to 
streamlining  and  continuous  improvement  efforts 
until  the  core  processes  are  world  class. 

This  task  is  a  continuation  of  SWOT  analysis 
and  is  best  performed  in  a  workshop  environment. 
Strategic  benchmarking  projects  should  also  focus 
on  core  competencies  so  that  the  organization  has  a 
basis  for  evaluating  status  with  respect  to  other 
organizations  with  similar  processes  and  identifying 
performance  gaps  that  need  attention  in  process 
improvement  projects. 

4.1.6  Determine  High«Level  Customer 
Requirements.  With  inputs  from  the  results  of  the 
tasks  described  above,  the  organizational  unit  is 
ready  to  identify  the  specific  product  and  service 
needs  of  its  customers.  This  analysis  will  provide 
the  basis  for  detailed  customer  requirements 
analysis  performed  during  business  planning  and  in 
process  improvement  projects.  It  is  important  that 
senior  managers  participate  in  this  task  so  that  there 
is  no  misunderstanding  of  how  all  of  the  elements 
of  the  strategic  plan  fit  together.  When  this  task  is 
complete,  the  organization  will  have  a  firm 
foundation  for  defining  a  program  of  process 
management  and  process  improvement  that 
everyone  in  the  organization  can  understand  and 
support.  From  this  point  on,  there  is  a  well-defined 
context  for  leadership  and  decision  making. 

Quality  function  deployment  (QFD)  also 
known  as  The  Voice  of  the  Customer 
is  an  excellent  technique  for  capturing  customer 
needs,  requirements,  and  desires  in  a  form  that  can 
be  readily  used  to  drive  improvement  projects.  This 
technique  can  consolidate  all  of  the  inputs  gained 
from  customer  surveys,  questioimaires,  interviews, 
focus  groups,  on-site  tours  and  inspections,  as  well 


as  the  data  resulting  from  brainstorming  and 
historical  research. 

This  task  can  be  scheduled  to  coincide  with 
strategic  benchmarking  because  both  usually  take 
the  same  amount  of  calendar  time  to  complete.  The 
results  produced  by  these  techniques  are 
complementary  with  respect  to  defining 
breakthrough  performance  objectives. 

4.1.7  Prepare  Breakthrough  Objectives.  While 
the  results  of  strategic  planning  have  many  uses 
within  the  organization,  one  of  the  most  important 
is  to  provide  data  that  can  be  used  to  develop  a 
series  of  breakthrough  objectives  that,  if 
accomplished,  move  the  organization  toward  its 
vision  or  desired  future  state.  Breakthrough 
objectives  along  with  process  vision  (developed 
later  in  the  methodology),  and  performance 
measures  (developed  next  in  the  methodology)  are 
the  only  necessary  inputs  to  process  improvement. 
With  these  data,  process  improvement  teams  can 
work  out  the  details  of  how  to  achieve  the 
breakthrough  objectives. 

A  breakthrough  objective  is  one  that  describes 
a  quantum  leap  in  one  or  more  performance  areas. 

If  a  logistics  process  averages  two  weeks  to  deliver 
a  spare  part,  a  breakthrough  objective  may  be  to 
reduce  that  time  to  one  or  two  days.  Entire 
processes,  companies,  and  even  industries  have 
been  established  on  this  principle  (Automated  Teller 
Machines,  Federal  Express,  and  personal  computers 
are  respective  examples). 

Because  breakthrough  objectives  are 
transforming  from  an  organizational  standpoint, 
they  must  be  developed  with  or  by  the  most  senior 
leaders  in  the  organization.  Breakthrough 
objectives  can  only  be  accomplished  as  top-down 
initiatives.  The  impacts  on  every  facet  of  the 
organization  are  profound,  and  the  risks  associated 
with  implementing  them  are  substantial.  Also  for 
the  same  reasons,  there  can  be  no  more  than  one  to 
three  breakthrough  objectives  in  the  strategic  plan. 
The  strategic  plan  should  not  be  cluttered  with 
minor  or  incremental  objectives  best  specified  in 
lower  level  business  or  operational  plans. 
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Breakthrough  objectives  are  developed  in  a 
workshop  environment  using  the  outputs  from  the 
previous  strategic  planning  tasks.  The  most 
important  input  to  this  workshop  is  usually  the 
strategic  benchmarking  report,  which  often 
establishes  the  basis  or  credibility  for  forming  a 
breakthrough  objective. 

4.1.8  Identify  Performance  Measures.  Without 
measures,  there  is  no  way  to  define,  monitor,  or 
manage  processes  or  process  improvement.  There 
is  no  accountability  for  results  because  there  is  no 
way  to  determine  results.  Every  strategic  and 
business  objective,  whether  it  applies  to  maintaining 
the  status  quo,  incrementally  improving  a  process, 
or  radical  process  innovation  is  defined  in  terms  of 
measures.  Four  categories  of  measures  that  must  be 
defined  for  every  strategic  or  business  plan 
objective: 

■  Fitness  for  Purpose  (FFP)  provides  a 
means  of  measuring  the  effectiveness  of 
a  process  or  product  with  respect  to 
st^eholder  interests. 

■  Conformance  to  Standard  (CTS) 
provides  a  means  of  measuring  the 
quality  aspects  of  a  process  or  product. 

■  Process  Time  Measures  (PTM)  quantify 
the  response  and  cycle  time 
characteristics  of  a  process. 

■  Process  Cost  Measures  (C$T)  weigh  the 
efficiency  and  productivity 
characteristics  of  a  process. 

Furthermore,  each  measure  category  should  be 
applied  to  each  of  the  four  categories  of  process 
stadceholders  as  appropriate. 

The  process  stakeholders  are  defined  in  Figure 
2-2  and  listed  below: 

■  Customers 

■  Higher  Authority 

■  Suppliers 

■  Resource  Providers 


This  means  that  there  are  16  possible 
measurement  categories  for  a  process,  each  of 
which  will  have  more  or  less  relevance  or 
importance  based  on  the  requirements  in  the 
strategic  plan  and  the  nature  of  the  process  itself. 
The  performance  cell  technique  can  be  used  to 
establish  measures  for  both  process  management 
and  process  improvement.  Please  see  Section  10  in 
this  guidebook  and  the  F/MPI  Performance  Cell 
Tutorial  for  more  information  on  performance  cells. 

Whether  the  performance  cell  technique  or 
other  means  are  used  to  define  performance 
measures,  performance  targets,  and  critical  success 
factors,  strategic  planning  is  not  complete  until  they 
are  defined.  This  is  critically  important  for  the 
breakthrough  objectives  defined  in  the  plan. 
Performance  measures  should  be  developed  off-line 
by  planning  team  members  and  reviewed  and 
approved  during  a  workshop  session. 

4.1.9  Document  the  Strategic  Plan.  Once  all  of 
the  above  tasks  have  been  completed,  the  next  task 
is  to  document  the  results  of  strategic  planning  in 
the  form  of  the  strategic  plan  itself.  A  suggested 
table  of  contents  for  the  strategic  plan  can  be  found 
in  the  F/MPI  Planning  Tutorial.  The  essence  of  a 
strategic  plan  is  substance  and  clarity,  not  volume. 

A  complete  strategic  plan  for  a  typical 
organizational  unit  should  take  no  more  than  ten 
pages  of  text  supplemented  with  charts,  diagrams, 
and  drawings  wherever  meaningful.  Backup  and 
substantiating  data  should  be  maintained  in  separate 
files  for  reference  and  for  use  in  the  succeeding 
planning  cycles. 

4.1.10  Review  and  Approve  the  Strategic  Plan. 

The  strategic  plan  is  subject  to  a  final  review  and 
approval  process  by  organizational  management  and 
higher  authority.  If  the  strategic  plan  is  a  valid 
subset  of  higher  authority  strategic  plans,  and  if  the 
senior  leadership  participated  in  the  planning 
process  as  recommended,  it  should  not  take  long  to 
secure  approval.  Once  the  plan  is  approved,  it 
should  be  briefed  in  whole  or  in  part  to  everyone  in 
the  organization.  Only  to  the  extent  that  everyone 
understands  the  strategic  objectives  of  the 
organization  can  they  direct  their  actions  to 
fulfilling  it. 


4-6 


Strategic  and  Business  Planning 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


This  concludes  the  strategic  planning  step  of 
the  F/MPI  methodology.  The  next  step  in  the 
planning  phase  is  to  develop  and/or  validate  the 
business  systems  plan. 

4.2  Step  2:  Develop/Validate  the  Business 

Systems  Plan 

The  Business  Systems  Planning  (BSP) 
methodology  was  introduced  by  IBM  in  1970  as  a 
way  to  incorporate  organizational  or  business 
strategy  into  information  systems  strategy.'^  Many 
derivatives  of  the  BSP  methodology  are  in  use  in 
DoD  components.  Functional  managers 
contemplating  process  improvement  efforts  will 
find  that  performing  or  updating  a  business  or 
information  systems  planning  study  provides 
valuable,  time-saving  information  that  will  enhance 
process  improvement  efforts. 

Business  systems  planning  is  concerned  with 
understanding  the  inter-relationships  of  process, 
organization,  data,  application  (functional) 
systems,  and  geotechnical  computer  and  data 
communications  platforms  as  they  relate  to  strategic 
and  business  objectives,  goals,  and  strategies. 

These  entities  already  exist  in  DoD  component 
organizations;  and  process  improvement  efforts 
should  understand  how  these  structures  may  enable 
or  constrain  modifications  to  the  existing 
information  infrastructure. 

The  objectives  of  a  business  systems  planning 
study  are  to: 

■  Determine  information  systems  priorities 

■  Plan  long-lived  information  systems 
based  on  enduring  business  processes 

■  Manage  systems  resources  to  support 
business  objectives 

■  Assign  systems  resources  to  high-retum 
projects 

■  Improve  relationships  between  functional 
and  technical  organizational  units. 

The  benefits  of  conducting  a  study  include: 


■  Coordination  of  process  improvement 
plans  with  technical  improvement  plans 

■  Assurance  that  the  data,  application,  and 
geotechnical  architectures  are  aligned 
with  functional  process  requirements 

■  Directed  information  systems  strategies 

■  Action  plans  and  resource  requirements 
for  information  systems  implementation 
strategies. 

Because  business  systems  planning  studies  are 
performed  (or  reviewed  and  updated)  prior  to 
launching  process  improvement  projects,  the 
principal  contribution  of  such  a  study  is  to  establish 
a  well-documented  baseline  for  systems 
architectures  as  an  input  to  process  improvement 
efforts.  Later,  as  the  process  improvement  project 
enters  the  Enterprise  Engineering  Phase,  these 
architectures  will  be  redesigned  to  accommodate  the 
needs  of  the  redesigned  process.  When  the  systems 
architectures  are  redesigned,  technical  staff  can 
ensure  that  systems  improvements  in  support  of  a 
redesign  process  are  properly  integrated  into  the 
existing  information  systems  infrastructure  in  a  way 
that  does  not  adversely  affect  other  functional 
processes. 

It  should  be  noted  that  business  systems 
planning  methods  were  developed  long  before  the 
concept  of  process  improvement  came  about.  Now 
that  functional  managers  are  expected  to  take  the 
lead  in  directing  information  systems  support, 
business  systems  planning  is  reduced  to  a 
supporting  role  in  process  improvement  efforts. 

This  does  not  invalidate  its  importance  in  ensuring  a 
stable  and  well-functioning  information  systems 
infrastructure. 

The  following  tasks  are  performed  in  the 
business  systems  planning  step: 

■  Review/validate  the  current  business 
systems  planning  architectures 

■  Identify  major  business  processes 
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■  Develop  the  business  process/ 
organizational  map 

■  Prepare/validate  information  systems 
architectures 

■  Review  and  approve  the  business 
systems  plan. 

This  guidebook  provides  an  overview  of  the 
business  systems  planning  methodology.  Please 
contact  your  technical  support  organization  for 
further  information  of  the  specific  methods  used  by 
them  to  accomplish  these  tasks. 

4.2.1  Review/Validate  Current  Business  Systems 
Plan.  Most  DoD  components  have  an  existing 
business  systems  plan  that  should  be  reviewed  and 
validated.  It  is  critically  important  that  this  review 
take  the  DoD  Enterprise  Model  into  consideration. 
Eventually,  all  functional  and  business  processes, 
and  supporting  information  systems  will  need  to 
conform  to  this  overarching  view  of  the  DoD 
enterprise. 

During  the  review,  elements  of  the  business 
systems  plan  that  do  not  conform  to  the  DoD 
Enterprise  Model,  or  that  are  out  of  date,  or  that 
may  be  affected  by  potential  process  improvement 
projects  should  be  noted  and  scheduled  for 
corrective  action.  If  the  existing  business  systems 
planning  study  is  over  five  years  old,  it  will  be 
worth  the  investment  to  conduct  another  study. 
Because  business  systems  planning  is  no  longer  the 
primary  engine  of  driving  improvement  projects, 
such  a  study  should  be  doable  in  less  than  one 
calendar  month. 

4.2.2  Identify  Major  Business  Processes.  The 

first  objective  of  a  business  systems  planning  study 
is  to  develop  or  validate  a  portfolio  of  current 
business  or  functional  processes.  Processes  are 
determined  by  interview  and  research  techniques 
independent  of  process  improvement  efforts  to 
ensure  that  all  functional  managers  in  an 
organizational  unit  agree  as  to  what  business 
processes  exist.  At  this  time,  processes  can  be 
given  an  acceptable  name  and  decomposed  into 
valid  subprocesses.  This  is  also  an  excellent  time  to 
bring  each  component’s  processes  into  alignment 
with  the  DoD  Enterprise  Model. 


The  strategic  plan  completed  in  the  previous 
task  is  the  starting  point  for  process  identification. 
Any  mission  changes  or  significant  changes  with 
respect  to  customer  service  may  result  in  the  need 
for  new  processes. 

The  rules  for  identifying  processes  include  the 
following: 

■  Processes  are  independent  of 
organizational  structure. 

■  Processes  are  significant  to  the  nature 
and  purpose  of  the  enterprise. 

■  The  naming  convention  for  processes  are 
verb-name  such  as  Design  Project  or 
Provide  Spare  Parts. 

■  Well-defined  processes  can  be  both 
aggregated  or  disaggregated,  which  is  to 
say  that  they  have  a  logical  structure. 

■  Process  redundancy  is  to  be  avoided. 

At  this  time,  breakthrough  objectives  in  the 
strategic  plan  should  be  thoroughly  studied  to 
determine  if  their  accomplishment  may  require  any 
modifications  to  the  portfolio  of  processes  for  the 
component.  It  is  quite  possible  that  a  radical 
improvement  called  for  by  the  strategic  plan  may 
call  for  new  levels  of  cross-functional  process 
integration,  or  eliminate  some  processes  or 
subprocesses.  Understanding  potential  impacts 
resulting  from  strategic  planning  will  help  guide  the 
completion  of  the  next  task. 

4.2.3  Develop  Process  Map.  A  process  map  or 
matrix  shows  the  relationships  between  business 
processes  and  organizational  (functional)  entities. 
Figure  4-2  illustrates  such  a  matrix. 

With  the  Process  v  Organizational  Matrix,  it  is 
easy  to  identify  functional  units  that  should  be  part 
of  any  process  improvement  effort.  If  the  Plan 
Project  process  is  to  be  reengineered,  the  Planning 
Division  and  the  Engineering  Division  must  be 
included  in  the  cross-functional  team,  and  the 
Constmction  Division  should  at  least  be  part  of  the 
review  team  for  process  improvement  deliverables. 


4-8 


Strategic  and  Business  Planning 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


\  Functional 

Process  \ 

Plan 

Division 

Engineer 

Division 

Construct 

Division 

Operate 

Division 

Conduct  Study 

♦ 
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Plan  Project 

* 
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Construct  Project 

♦ 
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Maintain  Project 

SI 

♦ 

♦  =  Primary  Responsibility,  S  =  Major  Involvement,  o  =  Minor  Involvement 

Figure  4-2.  Process  v  Organization  Matrix 


4.2.4  PrepareA^alidate  Architectures.  Business 
systems  planning  continues  with  the  preparation 
and/or  validation  of  several  other  matrices: 

■  Process  v  Data  Class 

■  Process  v  Automated  Information 
System  (AIS) 

■  AIS  V  Geotechnical  Platforms 

■  Business  Strategy  (Breakthrough 
Objective)  v  Process 

■  Business  Strategy  (Breakthrough 
Objective)  v  Organization 

■  Business  Strategy  (Breakthrough 
Objective)  v  Data  Class. 

The  use  of  matrices  can  help  ensure  that  all 
elements  of  process  improvement  are  understood  in 
terms  of  their  interrelationships.  Some  of  the 
specific  uses  include  the  following: 

■  Understanding  how  data  is  shared 
throughout  the  organization  and  between 
business  processes 

■  Illustrating  process  and  information 
system  interdependencies 

■  Determining  the  relative  importance  of 
data  with  respect  to  business  strategies 


■  Identifying  organizational 
responsibilities  and  ensuring  optimum 
participation  in  cross-functional  process 
improvement  projects 

■  Understanding  legacy  and  migration 
system  impacts  on  process  improvement 
efforts. 

In  summary,  business  systems  planning 
provides  an  excellent  medium  for  synchronizing  the 
interests  of  functional  users  with  those  in  the 
technical  support  organizations.  The  matrices  and 
other  deliverables  inherent  in  business  systems 
planning  ensure  clarity  and  precision  of  terminology 
and  language,  which  are  critical  to  process 
improvement  project  success.  The  most  important 
deliverable  is  the  data  architecture,  which  is  the 
basis  for  controlling  cross-functional  operation  of 
end-to-end  business  processes. 

4.2.5  Prepare,  Review  and  Approve  the  Business 
Systems  Plan.  The  final  task  in  this  step  is  to 
prepare  the  formal  documents  for  the  business 
systems  planning  study.  These  documents  need  not 
be  as  extensive  as  required  in  the  BSP  methodology 
now  that  the  process  improvement  methodology 
supplants  many  of  the  functions  of  BSP. 
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A  reasonable  business  systems  planning  study 
report  will  have  the  following  sections: 

■  Executive  summary 

■  Background  section  explaining  the 
objectives  of  the  study  and  the  methods 
used 

■  Study  perspective  highlighting  the 
objectives  expressed  in  the  strategic  plan, 
especially  the  breakthrough  objectives 

■  Findings  with  respect  to  information 
systems  needs,  requirements,  and 
opportunities 

■  Potential  constraints  based  on  the 
information  systems  infrastructure  that 
may  hinder  process  improvement  efforts 
and  suggested  means  of  dealing  with 
these  constraints 

■  Information  systems  strategies  and 
recommendations  based  on  the 
implications  of  the  strategic  plan 

■  High-level  architectures  and  matrices  for 
use  in  process  improvement  projects 

■  Appendices  of  detailed  architectures 
including  the  application  portfolio  and 
data  structures. 

The  business  systems  plan  should  be  reviewed 
and  approved  by  all  functional  managers  in  the 
organizational  units  covered  by  the  plan.  Once 
approved,  this  plan,  along  with  the  strategic  plan  are 
passed  on  to  the  next  step  in  the  process 
improvement  methodology:  business  planning. 

4.3  Step  3:  DevelopA^alidate  the  Business  Plan 

Business  planning  proceeds  from  strategic 
planning.  While  the  strategic  plan  establishes  broad 
objectives  and  goals  over  a  long-range  planning 
horizon,  the  business  plan  specifies  detailed 


objectives  that  can  be  accomplished  within  a  single 
business  year  cycle.  While  the  strategic  plan  is 
complete  once  the  objectives,  goals,  and  broad 
strategies  are  in  place,  the  business  plan  always 
proceeds  to  the  action  or  implementation  plan  stage 
for  all  objectives.  The  strategic  plan  is  reviewed 
and  updated  annually,  but  the  business  plan  is 
monitored  and  measured  on  a  monthly  or  quarterly 
basis.  While  the  strategic  plan  is  constructed  on  the 
basis  of  explicitly  stated  assumptions  about  what 
will  happen  or  not  happen  outside  the  organization 
(the  environment),  the  business  plan  is  developed  as 
if  the  assumptions  in  the  strategic  plan  were  facts. 

The  purpose  of  the  annual  business  plan  is  to 
concentrate  all  business  unit  activities  on  delivering 
products  and  services  to  an  established  base  of 
internal  and/or  external  customers;  and  satisfying 
other  defined  stakeholder  requirements.  The 
business  plan  should  focus  the  consumption  of 
resources  on  producing  required  and  desired  process 
outcomes  for  all  business  processes  served  by  the 
business  unit.  The  business  plan  specifies  what 
needs  to  be  done  by  the  business  unit  and  assigns 
responsibilities,  performance  measures,  and 
schedules  for  completing  work. 

The  business  plan  is  designed  to  help  the 
business  unit  accomplish  three  broad  objectives: 

■  Raise  the  business  unit  to  a  higher  level 
of  performance  with  respect  to  its 
purpose  and  mission 

■  Provide  a  framework  for  making  better 
decisions  with  respect  to  current  assigned 
operating  responsibilities 

■  Enable  managers  and  employees  to  be 
more  proactive  in  managing  the  events 
that  may  affect  the  business  unit. 

There  are  three  components  in  a  business  plan: 

■  Program  Plan 

■  Operations  Plan  (Process  Management 
Plan) 

■  Process  Improvement  Plan. 
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The  program  plan  is  oriented  to  a  function 
rather  than  to  a  process.  It  sets  forth  the  policies, 
programs,  procedures,  standards  and  training 
requirements  that  will  be  in  force  over  the  planning 
period  for  the  functional  unit.  It  also  contains  the 
resource  plan,  which  includes  staffing,  facilities, 
equipment,  materials,  contracting,  and  funding 
requirements.  The  program  plan  must  be 
synchronized  with  the  other  two  components  in  the 
business  plan  that  are  oriented  to  processes. 

The  operations  plan  is  concerned  with  the 
management  of  processes  on  a  day-to-day  basis.  It 
establishes  standards  of  performance,  based  on  key 
indicators  and  measures,  and  assigns  responsibilities 
for  maintaining  process  performance  within 
allowable  variances.  The  operations  plan  may  also 
include  continuous  process  improvement  objectives. 


The  process  improvement  plan  is  concerned 
entirely  with  the  breakthrough  (process 
improvement)  objectives  specified  in  the  strategic 
plan.  This  is  the  part  of  the  business  plan  that 
specifies  how  the  breakthrough  objectives  are  going 
to  be  accomplished. 

Both  the  operations  and  the  improvement 
plans  are  cross-functional  in  nature.  This  means 
that  business  planning  sets  the  stage  for  process 
management  and  improvement.  Once  the  business 
plan  is  in  place,  each  functional  unit  knows  its  role 
in  process  management  and  improvement,  and  how 
functional  controls  and  resources  must  be  aligned  in 
support  of  processes. 

Figure  4-3  shows  the  relationships  between 
strategic  and  business  planning  and  the  sources  for 
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constructing  a  sound  business  plan.  Along  with  the 
strategic  plan  itself  (and  business  systems  plan),  the 
other  two  primary  inputs  to  business  planning  are 
customer  requirements  and  additional  information 
obtained  from  environmental  analysis.  Customer 
needs  and  requirements  can  be  obtained  in  many 
ways,  but  using  Quality  Function  Deployment 
(QFD)  is  a  proven  technique  for  generating  and 
consolidating  customer  requirements  in  the  most 
useful  manner.  (See  Section  10  for  more 
information  on  QFD.)  The  environmental  analysis 
in  support  of  business  planning  should  focus  on 
searching  for  best  business  practices  and  innovative 
uses  of  technology. 

Business  planning  is  best  conducted  in  a 
workshop  environment  taking  advantage  of  the 
combined  knowledge,  skill,  and  experience  of 
functional  and  process  managers,  professionals,  and 
staff.  QFD  and  best  practices  benchmarking  help 
ensure  that  planning  teams  are  not  so  inwardly 
focused  that  they  miss  opportunities  for  innovative 
process  improvement. 

Business  planning  should  take  no  more  than 
five  days,  not  including  the  time  it  takes  to  conduct 
best  practices  benchmarking  or  survey  and 
interview  customers.  These  activities  should  be 
performed  in  advance  of  the  planning  workshops. 

The  following  tasks  are  performed  in  the 
business  planning  step: 

■  Review  strategic  and  business  systems 
planning  materials 

■  Develop  preliminary  process  notebook 

■  Conduct  detailed  customer  requirements 
analysis 

■  Categorize  process  improvement  projects 

■  Develop  the  business  plan  report 

■  Review  and  approve  business  plans. 

See  the  F/MPI  Planning  Tutorial  for 
information  on  business  planning.  Also  review  the 
Hoshin  planning  technique  in  Section  10  of  this 
guide  for  more  information. 

4.3.1  Review  Strategic  and  Business  Systems 
Plans.  The  strategic  and  business  systems  planning 
outputs  are  the  starting  point  for  business  planning. 


It  is  vital  that  the  resulting  business  plan  support  the 
requirements  and  objectives  established  by  senior 
leadership.  The  status  of  each  process  supported  by 
the  functional  unit  doing  business  planning  should 
be  reviewed  to  determine  its  appropriate  emphasis 
in  the  business  plan.  All  strategic  objectives  should 
be  analyzed  to  determine  the  role  the  functional  unit 
may  have  in  achieving  them.  If  there  are  multiple 
objectives,  they  should  be  prioritized,  especially  if 
there  is  doubt  that  the  necessary  resources  will  be 
available  to  accomplish  all  of  them. 

A  matrix  is  an  excellent  technique  for 
organizing  this  type  of  information.  Use  matrices  to 
show  the  relationships  of  objectives  by  process  and 
objectives  by  functional  element.  Potential  cross¬ 
functional  interactions  can  be  recognized  and 
recorded  in  this  task. 

4.3.2  Develop  Preliminary  Process  Notebook.  A 

process  is  a  critical  entity  within  the  enterprise. 
Much  that  can  be  known  about  a  process  should  be 
documented  for  use  by  process  managers  and 
process  improvement  teams.  Establishing  a  process 
notebook  is  one  way  of  doing  this.  A  process 
notebook  can  be  as  simple  as  a  word-processed  text 
document,  or  as  robust  as  a  multimedia  file  with 
text,  graphics,  tables,  spreadsheet  data,  and  even 
audio  and  video  segments — ^all  referring  to  process 
characteristics.  It  can  also  function  as  an  historical 
record  of  all  process  improvement  actions  taken, 
which  can  facilitate  future  process  improvement 
actions.  The  type  of  data  that  can  be  maintained  in 
the  process  notebook  may  include  the  following: 

■  Process  description  supported  by  charts 
and  diagrams 

■  Process  deployment  map  showing 
functional  relationships 

■  Stakeholder  identification  and 
interactions  with  the  process 

■  Descriptions  of  output  products  and 
services 

■  Critical  success  factors  and  key  results 
areas 

■  Existing  measures 

■  Estimated  cycle  time  for  major  outputs 
(models  and  tables) 

■  Estimated  costs  for  major  outputs 
(models  and  spreadsheets) 
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■  Process  personnel  descriptions  (duties 
and  responsibilities) 

■  Deployed  technology  (configuration 
maps,  models,  and  architectures) 

■  Known  process  strengths  and 
weaknesses 

■  Known  product/service  strengths  and 
weaknesses 

■  Current  improvement  objectives  and 
status 

■  Relevant  directives  and  guidance 

■  Existing  (in-house)  training  programs. 

4.3.3  Conduct  Detailed  Customer  Requirements 
Analysis.  The  next  task  is  to  construct  a  detailed 
customer  requirements  matrix  for  the  process  based 
on  the  responsibilities  of  the  functioned  unit.  If 
there  are  no  current  baseline  models  for  the  process, 
it  will  be  difficult  to  determine  requirements  for 
internal  customers  so  the  results  obtained  will  only 
be  preliminary. 

Techniques  that  can  be  used  to  capture  this 
information  include  surveys,  questionnaires, 
interviews,  focus  groups,  brainstorming,  site  visits, 
quality  functional  deployment  and  process 
benchmarking.  As  information  is  gathered  and 
analyzed,  it  should  be  summarized  in  the  process 
notebook. 

At  the  conclusion  of  this  task,  the  following 
data  should  be  recorded: 

■  Customer/process  matrix  showing  all 
internal  and  external  customers 

■  Customer/product  and  service  matrix 

■  Requirements  by  product  and  service 

■  Stakeholder  interests. 

This  information  will  be  used  to  establish 
process  management  and  process  improvement 
requirements  and  objectives  in  the  business  plan. 

4.3.4  Categorize  Process  Improvement  Projects. 
Process  improvement  projects  can  be  organized  into 
one  of  three  levels  as  described  in  Section  2  of  this 
guide.  It  is  important  that  as  process  improvement 
actions  or  projects  are  commissioned,  the  general 
scope  or  level  of  process  improvement  be  well- 


understood  by  the  improvement  teams.  Experience 
has  shown  that  it  is  best  to  confine  an  improvement 
team  to  only  one  level  of  improvement  project. 

This  means,  for  instance,  that  minor  incremental 
improvements  should  not  be  attempted  during  a 
process  reengineering  effort.  Such  minor  changes 
can  conflict  with  the  objectives  of  the  reengineering 
effort  and  confuse  the  staff. 

All  proposed  process  improvement  actions  and 
projects  should  be  categorized  in  the  business  plan 
into  one  of  three  levels: 

■  Continuous  Process  Improvement 

■  Process  Redesign 

■  Process  Reengineering. 

4.3.5  Develop  Business  Plan.  The  next  task  is  to 
develop  the  actual  business  plan.  All  the  data  and 
information  needed  to  do  this  should  be  available  as 
a  result  of  performing  the  previous  steps  and  tasks 
in  the  planning  phase  of  the  methodology.  If  steps 
or  tasks  were  omitted,  it  will  be  much  more  difficult 
to  achieve  a  business  plan  that  accomplishes  the 
general  objectives  of  planning  listed  in  Section  4.3. 
The  business  plan  will  contain  three  major 
components,  as  described  in  the  following 
subsections. 

4.3.5.1  Program  plan  component.  The  purpose  of 
this  component  is  to  organize  the  business  unit  for 
action.  This  part  of  the  business  plan  has  a 
functional  orientation.  The  actions  themselves  to  be 
performed  by  the  business  unit  will  be  developed  in 
the  other  two  components  of  the  business  plan:  this 
component  provides  the  foundation  for  carrying  out 
the  objectives  of  the  other  two  components.  The 
general  contents  of  the  program  plan  are  listed  here 
and  more  fully  described  in  the  F/MPI  Planning 
Tutorial. 

■  Functional  objectives  and  goals 
(improving  the  functional  unit) 

■  Program  Description  (related  to  each 
functional  objective) 

■  Milestones  for  each  functional  objective 

■  Functional  Organizational  Structure 
(including  staffing) 

■  Budgets  and  Funding 

■  Functional  Policies  and  Practices 
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■  Functional  Procedures 

■  Standards  of  Excellence  and 
Performance. 

4.3.5.2  Operations  plan  component.  The  purpose 
of  this  component  is  to  set  a  performance 
management  plan  in  place  for  all  processes  that  are 
not  scheduled  for  process  improvement  (other  than 
continuous  process  improvement,  which  should 
always  be  in  place.)  The  operations  plan  (which 
can  also  be  cdled  the  process  management  plan) 
identifies  the  critical  success  factors,  measures,  and 
allowable  variances  for  all  processes.  It  assigns 
responsibilities  for  all  process  activities  and 
includes  contingency  plans  to  be  activated 
whenever  process  performance  is  out  of  variance. 
The  F/MPI  Planning  TYitorial  explains  in  detail  how 
to  construct  the  operations  plan. 

4.3.5.3  Process  Improvement  Plan.  The  process 
improvement  plan  is  the  most  important  component 
of  the  business  plan  because  it  establishes  how  the 
strategic  breakthrough  objectives  are  going  to  be 
accomplished.  The  Hoshin  planning  technique  is 
recommended  for  constructing  this  part  of  the  plan. 
With  Hoshin  planning,  every  breakthrough 
objective  is  decomposed  into  enabling  objectives 
until  it  is  possible  to  construct  an  implementation 
plan  with  tasks,  schedules,  milestones,  resources, 
and  assignments.  Hoshin  planning  combines  the 
best  practices  of  management  by  objective  and 
project  management.  It  is  well  suited  for  plaiming 
improvement  projects. 

It  is  important  to  note  that  the  process 
improvement  plan  is  concerned  with  WHAT  must 
be  accomplished  to  fulfill  the  strategic  breakthrough 
objectives,  not  HOW  it  is  going  to  be  done.  The 
HOW  of  process  improvement  is  dealt  with  in  the 
next  phase  of  the  improvement  methodology, 
process  reengineering.  The  F/MPI  Planning 
Tutorial  explains  in  detail  how  to  construct  the 
improvement  plan.  In  general,  the  following  data 
are  included  in  the  plan; 

■  Candidate  Process  Owner(s).  There 
should  be  one  executive  process  owner, 
sponsor,  or  proponent  for  the  overall 
effort  and  representatives  from  each  of 


the  major  functional  units  who  will 
participate  in  the  improvement  project. 

■  Candidate  Project  Managers.  Once  the 
process  improvement  project  is 
authorized,  there  will  need  to  be  an 
assigned  project  manager.  In  this  task, 
suitable  project  managers  can  be 
identified. 

■  Objective  Decomposition.  The 
breakthrough  objective  from  the  strategic 
plan  must  be  broken  down  into  its 
enabling  objectives.  Each  objective  has 
a  quantified  goal,  strategy  for 
implementation,  performance  measure, 
and  responsible  person.  The 
decomposition  process  continues  until  it 
is  possible  to  construct  an 
implementation  plan  (generally  after  two 
or  three  levels  of  decomposition.) 

■  Implementation  Deployment  Plan.  The 
deployment  plan  shows  the  participation 
of  the  functional  units  in  fulfilling  the 
requirements  of  the  objective.  It  is  the 
basis  for  setting  up  cross-functional 
teams. 

■  Implementation  Action  Plan.  The  action 
plan  sets  the  schedule  for  completing 
the  objectives.  With  Hoshin  planning, 
as  the  objectives  at  each  level  are 
accomplished,  the  higher  level  objective 
is  automatically  accomplished.  Also, 
there  is  traceability  from  the  lowest-level 
action  through  the  enabling  objectives  all 
the  way  to  the  strategic  breakthrough 
objective. 

It  is  usually  necessary  to  adjust  the  other 
components  of  the  business  plan  after  completing 
this  component.  Before  business  planning  can  be 
considered  complete,  all  three  components  should 
be  mutually  complementary  and  supporting. 

4J.6  Review  and  Approve  Business  Plans.  The 
final  task  in  this  step  is  to  complete  the 
documentation  for  the  business  plan  and  submit  it  to 
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higher  authority  for  review  and  approval.  The 
approval  of  the  business  plan  is  facilitated  when 
functional  units  concerned  with  a  single  process 
have  worked  together  to  ensure  that  the  plans 
submitted  by  each  functional  element  are 
compatible  with  respect  to  shared  processes.  The 
business  planning  technique  presented  in  this  guide 
supports  the  concept  of  process  management  within 
a  functional  organizational  structure. 

It  is  possible  to  adopt  process  management 
principles  while  still  retaining  a  functional 
organizational  structure  providing  planning  is  not 
done  in  isolation.  Functional  units  are  still 
important  because  it  is  in  the  functional  unit  that  a 
body  of  expertise,  standards  of  performance,  skill 
development,  and  resources  can  best  be  tapped  and 
managed. 

4.4  Step  4:  Construct  Performance  Cells 

Traditional  planning  techniques,  based  on  the 
functional  (hierarchical)  organizational  model,  are 
not  sufficiently  robust  to  generate  the  type  of 


planning  information  needed  for  performance-based 
management.  This  is  because  traditional  planning 
techniques  take  a  top-down  hierarchical  view  of  the 
organization,  and  express  all  planning  objectives 
and  goals  from  the  point  of  view  of  corporate 
management.  Other  stakeholder  interests  are  only 
accounted  for  incidentally  and,  even  then,  not  in  any 
coordinated  or  integrated  fashion.  Traditional 
planning  techniques  can  give  process  improvement 
teams  vital  information  concerning  strategic  and 
business  objectives,  but  typically  do  not  express 
those  objectives  in  terms  of  performance  targets. 

Nor  do  these  plans  typically  capture  baseline 
performance  data  for  use  in  performance  gap 
analysis. 

The  Performance  Cell  Technique  (PCT)  is 
designed  to  provide  a  bridge  that  links  business 
planning,  process  identification,  and  process 
improvement  as  shown  in  Figure  4-4.  Once 
established  in  an  organization,  PCT  furnishes 
critical  performance  data  (baseline  and  target)  that 
together  with  business  planning  improvement 
objectives  function  as  a  charter  for  process 
improvement  action  teams.  Please  refer  to  the 
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F/MPI  Performance  Cell  Tutorial  for  detailed 
information  on  how  to  employ  the  performance  cell 
technique. 

The  following  tasks  are  performed  in  this  step: 

■  Select  performance  cell  by  process 

■  Assign  responsibility  for  performance 
cell  development 

■  Develop  performance  cells 

■  Review  and  approve  the  performance 
cell  document. 

4.4.1  Select  Performance  Cell  Measures  by 

Process.  Every  process  must  recognize  and  satisfy 
stakeholder  interests.  Most  of  the  literature  on 
process  improvement  stresses  satisfying  customer 
requirements,  which,  of  course,  is  the  focus  of 
process  management  and  improvement.  But  there 
are  other  stakeholders  in  the  process  who  have 
legitimate  claims  on  process  performance.  For 
instance,  in  the  private  sector,  a  company  that 
satisfied  its  customers  but  not  its  shareholders 
would  not  be  considered  a  successful  company.  In 
the  public  sector,  processes  must  satisfy  the  citizens 
who  pay  for  the  process  as  well  as  those  who 
receive  services. 

There  are  four  principal  stakeholders  of 
interest: 

■  Customers  are  the  recipient  of  output 
products  and  services  produced  by  the 
process.  Customers  are  the  focus  of 
process  improvement  efforts. 

■  Suppliers  provide  the  input  data  and 
materials  used  by  the  process  to  produce 
outputs.  In  the  information  age, 
suppliers  are  best  treated  as  business 
partners  with  the  common  objective  of 
satisfying  process  objectives.  Together, 
customers  and  suppliers  make  up  a 
value-chain  consisting  of  value-added 
activities  that  progressively  transform 
inputs  into  useful  outputs. 

■  Higher  authorities  set  the  controls  on  a 
process.  Controls  consist  of  policies, 
directives,  procedures,  requirements. 


product  standards,  performance 
standards,  budgets,  and  other  constraints 
on  process  performance. 

■  Resource  providers  make  available  the 
facilities,  equipment,  people,  and  funds 
that  enable  the  process  to  transform 
inputs  into  higher- value  outputs. 
Together,  higher  authorities  and  resource 
providers  make  up  a  control-chain 
consisting  of  enablers  of  and  constraints 
on  process  performance. 

Process  management  is  concerned  with 
optimizing  the  value-chain;  functional  management 
is  concerned  with  optimizing  the  control-chain. 
Process  improvement  principles  provide  an 
opportunity  to  optimize  both  simultaneously. 

There  are  four  categories  of  process  measures: 

■  Fitness  for  purpose  measures  how  well  a 
product  or  service  satisfies  customer 
requirements. 

■  Conformity  to  standard  measures  how 
well  a  product  or  service  satisfies 
standards  of  performance  norms. 

■  Process  time  measures  how  responsive  a 
process  is  to  customer  requests  and  how 
many  outputs  it  can  deliver  in  a  given 
unit  of  time. 

■  Process  costs  measure  how  efficient  the 
process  is  in  its  consumption  of 
resources. 

If  we  build  a  matrix  of  process  stakeholders 
vis-^-vis  process  measures,  we  will  have  16  cells  in 
the  matrix,  each  of  which  relates  a  measure  to  a 
stakeholder.  The  first  task  in  this  step  is  to 
determine  which  of  the  16  performance  cells  are 
relevant  for  each  process  identified  by  business 
systems  planning. 

4.4.2  Assign  Responsibility  for  Performance  Cell 
Development.  The  second  task  is  to  assign 
responsibility  for  performance  cell  development  for 
each  process.  Identifying  performance  cells 
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measures  is  a  non-trivial  task  because  each  measure 
must  be  relevant  to  a  stakeholder’s  interest  and 
there  must  be  a  way  for  the  process  to  generate 
measurable  data.  This  means  that  the  person 
selected  to  develop  performance  cells  must  be  both 
experienced  in  the  process  and  able  to  communicate 
well  with  stakeholders  in  the  process. 

4.4.3  Develop  Performance  Cells.  The  next  task 
is  to  populate  the  performance  cells.  Appendix  A  of 
the  F/MPI  Performance  Cell  Tutorial  contains 
guidance  on  developing  measures  for  each  of  the  16 
performance  cells.  Figure  4-5  illustrates  a 
completed  performance  cell.  The  specific  contents 
of  the  performance  cell  depend  heavily  on  the 
process  itself  and  the  expectations  of  the  indicated 
stakeholder.  But  once  the  task  is  completed, 


process  managers  and  process  improvement  teams 
will  have  specific  objectives  to  guide  their  process 
management  and  process  improvement  efforts. 

Specific  measures  can  include  baseline  or 
current  measures,  target  or  objective  measures 
based  on  management  expectations,  and/or 
measures  based  on  specific  scenarios  (scenario 
analysis).  For  example,  a  logistics  process  would 
have  different  performance  measure  objectives  in 
peacetime  than  in  wartime.  Performance  cells 
provide  a  means  of  recording  this  kind  of  data. 

4.4.4  Review  and  Approve  Performance  Cells. 

Once  a  set  of  16  performance  cells  for  each  process 
has  been  developed,  they  should  be  submitted  to  all 
process  managers  for  review  and  approval. 


C^STOMER/FfTOES^  FOR  PURPOSI 

E  PERFORMANCE 

Priority:  3/16 

Weight:  1.0 

General  Business  Objective 

We  will  strive  to  maximize  the  fitness  for  purpose 

of  all  our  ouput  products  and  sen/ices  by  working 

with  our  customers  (process  owners)  to  meet  and 
exceed  all  customer  requirements. 

Key  Indicator 

Annual  Customer  Satisfaction  Survey 

Critical  Success  Factor 

15%/year  increase  in  Customer  Product  Utilization 

Principle  improvement 

Competitive  Benchmarking 

Techniques 

Quality  Function  Deployment 

Item/Measure 

Unit  of 

Baseline 

Target 

Measure 

Performance 

Performance 

Output  Volume 

Units/Mon 

4,500 

6,000 

Number  of  Customers 

Units 

45 

50 

Satisfaction  Rating 

Percent 

77% 

92% 

Requests  per  Customer 

Ratio 

10 

12 

Courtesy  Telecalls 

#1  /  Month 

1 

4 

Est.  Market  Share 

Percent 

15% 

25% 

Est.  Market  Penetration 

Percent 

50% 

50% 

Figure  4'5.  Performance  Cell  Example 
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Performance  cells  provide  an  excellent  means  of 
ensuring  that  all  functional  managers  involved  with 
a  process  have  a  common  understanding  of  what 
constitutes  superior  process  performance. 
Performance  cells  also  assist  in  reducing  the  amount 
of  subjectivity  in  process  management  and 
improvement  by  encouraging  the  development  of 
specific  measures  that  reflect  total  process 
performance,  not  just  customer  satisfaction  (which 
is  not  sufficient  in  government  sector  processes.) 

4.5  Step  5:  Establish  Process  Improvement 

Project 

This  step  is  performed  when  the  strategic  plan 
has  directed  the  formation  of  a  process 
improvement  project  by  virtue  of  including  one  or 
more  breakthrough  objectives.  At  this  point,  all  of 
the  information  needed  by  a  process  improvement 
team  has  been  recorded  in  the  strategic  plan, 
business  systems  plan,  and  annual  business  plan. 

If  performance  cells  were  constructed  for  the 
processes  needing  improvement,  process 
improvement  teams  will  also  have  specific 
performance  objectives  to  guide  their  process 
improvement  efforts. 

When  this  step  is  completed,  all  planning 
activities  will  have  been  accomplished.  This  means 
process  improvement  teams  will  be  ready  to 
move  to  Phase  2  of  the  methodology,  process 
reengineering.  The  following  tasks  are  performed 
in  this  step,  which  when  completed  establish  a 
process  improvement  project: 

■  Specify  process  improvement  project 

■  Select  and  confirm  a  process  manager 
and  project  manager 

■  Develop  and/or  validate  the  process 
deployment  map 

■  Record  functional  management 
considerations 

■  Document  the  scope/mission/objectives 
of  functional  elements 

■  Select  and  train  the  cross-functional 
process  improvement  team 

■  Develop  a  preliminary  process  vision 

■  Develop  the  process  improvement 
strategy 


■  Develop  the  project  plan 

■  Review  and  approve  the  project  plan. 

4.5.1  Specify  Process  Improvement  Project.  A 
process  improvement  project  is  an  expensive  and 
risky  undertaking.  If  the  objective  is  true  process 
reengineering,  the  project  may  extend  for  two  years 
or  more  and  consume  not  only  funding  resources, 
but  also  huge  amounts  of  intellectual  capital  of 
people  who  otherwise  would  be  doing  something 
else.  For  these  reasons,  project  improvement 
projects  must  be  commissioned  by  higher  authority 
based  on  the  criticality  of  the  breakthrough 
objectives  in  the  strategic  plan. 

The  process  improvement  project  must  be 
funded  through  the  planning  stage — this  step.  The 
chief  output  of  this  step  is  a  project  plan  that  will 
include  complete  process  improvement  project  cost, 
time  and  sta^g  estimates  with  contingencies.  The 
process  improvement  project  (planning  step)  should 
be  formally  inaugurated  with  an  assigned  executive 
sponsor  and  a  letter  to  proceed  that  specifies  initial 
funding  and  planning  objectives. 

4.5.2  Select/Confirm  Process  and  Project 
Manager.  The  first  and  most  important  decision 
that  is  made  is  the  selection  of  the  project  manager. 
The  project  manager  should  be  experienced  in 
project  management,  knowledgeable  of  the  process 
to  be  improved,  and  equipped  with  superlative 
communications  and  team  skills.  The  F/MPI 
Project  Manager’s  Guidebook  contains  a  complete 
listing  of  the  specific  skills  needed  by  a  project 
manager  and  a  complete  catalogue  of  general 
project  management  duties  and  responsibilities. 

4.5  J  Develop/Validate  Process  Deployment 
Map.  The  planning  activities  described  above 
should  have  produced  a  process  deployment  map. 
This  map  must  be  reviewed  and  confirmed  by  the 
project  manager  because  it  will  be  the  basis  for 
staffing  the  project  improvement  team  and 
coordinating  all  process  improvement  actions  and 
communications.  The  process  deployment  map 
shows  the  relationship  of  the  process  to  the 
functional  elements  that  support  the  process.  It  also 
indicates  the  level  of  responsibility  and  involvement 
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of  each  functional  element  in  the  process.  The 
process  deployment  map  should  be  reproduced  in 
wallchart  form  and  posted  in  the  project  room  for 
easy  reference. 

4.5.4  Identify  Functional  Management 
Considerations.  One  of  the  first  duties  of  the 
project  manager  is  to  develop  an  understanding  with 
each  of  the  functional  managers  involved  in  the 
process.  They  should  agree  on  the  current  status  of 
the  process  with  respect  to  strategic  and  business 
plans,  and  accept  of  the  improvement  objectives  and 
goals  described  in  the  strategic  and  business  plans. 

It  is  not  enough  that  these  plans  have  been  reviewed 
and  accepted  by  higher  authority;  they  must  also  be 
endorsed  by  the  process  owners  who  are  the 
managers  of  the  functional  units. 

Each  functional  manager  should  imderstand 
and  concur  with  the  following: 

■  Process  baseline  status  as  indicated  by 
performance  cell  measures  or  other 
means 

■  Validity  of  the  process  deployment  map 

■  Assignment  of  improvement  objectives 
with  respect  to  the  process 

■  Degree  of  participation  required  of  the 
functional  manager  and  a  preliminary  list 
of  candidates  for  assignment  to  the 
improvement  team 

■  The  charter  that  launched  the  process 
improvement  project 

■  The  proposed  method  of  designing  the 
process  improvement  project — especially 
how  communications  will  occur  and 
project  status  will  be  reported 

■  Specific  considerations  expressed  by  the 
functional  managers  with  respect  to  the 
process  and  the  improvement  project. 


4.5.5  Document  Scope/Mission/Objectives  of 
Functional  Elements.  At  this  point,  the  project 
manager  should  be  able  to  construct  a  statement  of 
project  improvement  mission,  scope  and  general 
objectives.  It  may  even  be  possible  at  this  point  to 
document  some  or  all  of  the  performance  measures 
that  will  be  used  to  design  the  improvement  project 
and  measure  its  success.  This  will  be  especially 
true  if  the  performance  cell  technique  was  used. 
Note  that  we  recommend  completion  of  this  task 
before  the  actual  process  improvement  team  is 
formed,  because  the  project  manager  should  achieve 
this  understanding  with  the  functional  managers  to 
optimally  staff  the  improvement  project. 

4.5.6  Select/Tirain  Cross-Functional  Process 
Improvement  Team.  At  this  point  it  is  possible  to 
select  staff  members  to  work  on  the  process 
improvement  plan.  This  must  be  done  with  the  full 
cooperation  and  support  of  the  functional  managers, 
and  with  reference  to  the  process  deployment  map. 
Staff  members  should  be  trained  in  process 
improvement  skills  including  change  management 
and  technology  deployment.  The  F/MPI  Training 
Guide  discusses  the  specific  training  requirements 
for  this  task. 

Until  the  project  plan  has  been  reviewed  and 
approved  and  resources  are  made  available  to 
continue  the  project,  it  is  only  necessary  to  have  a 
small  team  of  people  who  are  highly  knowledgeable 
of  the  process.  These  team  members  should  be 
process  and  subprocess  managers  who  understand 
both  the  outputs  of  the  process  and  the  primary 
customer  groups  who  benefit  from  these  outputs. 

4.5.7  Develop  a  Preliminary  Process  Vision.  This 
is  a  most  important  task  in  the  improvement  project 
planning  step.  In  a  workshop  environment,  project 
team  members  will  endeavor  to  create  the  process 
vision  that  will  ultimately  guide  all  process 
improvement  efforts. 

The  key  activities  in  this  task  include  the 
following:* 


8  See  Davenport,  chapter  6,  for  a  full  discussion  of  process  visioning. 
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■  Assess  existing  business  strategy 
(strategic  and  business  plans)  for  process 
directions.  This  provides  a  foundation 
for  constructing  the  process  vision. 

■  Consult  with  process  customers  for 
performance  objectives.  This  activity 
supplements  the  data  collected  in  the 
process  notebook  and  the  performance 
cell  descriptions  for  the  process.  If  a 
process  notebook  was  not  constructed 
earlier  in  the  methodology  and/or 
performance  cells  were  not  developed, 
this  step  must  supply  all  vital  data. 

■  Conduct  a  benchmark  program  to 
develop  or  validate  process  performance 
targets  and  to  discover  innovative  uses 
of  technology  to  improve  process 
performance  (best  practices.)  Results  of 
using  the  QFD  technique  should  also  be 
included  in  this  activity. 

■  Formulate  process  improvement 
performance  objectives.  This  activity 
validates  the  performance  objectives 
developed  in  the  process  improvement 
component  of  the  business  plan.  It 
should  be  remembered  that  functional 
managers  constructed  the  business  plan, 
and  it  is  now  necessary  for  the  process 
improvement  team  to  validate  and/or 
revise  these  objectives  based  on  the 
results  of  the  activities  above. 

It  should  also  be  remembered  that 
process  improvement  itself  is  a  highly 
iterative  process,  and  it  is  always 
necessary  to  review  and  validate 
previous  deliverables  as  new  information 
is  gained.  This  activity  continues  until 
this  question  can  be  answered  to 
everyone’s  satisfaction:  “What  business 
objective  is  this  process  suppose  to 
accomplish?” 

■  Develop  process  attributes.  Process 
attributes  are  the  specific  strategies  for 
accomplishing  the  process  objective. 
They  form  the  principles  of  process 
performance  and/or  the  concept  of 


operation.  They  include  such  categories 
as  technology,  people,  delivery  of 
service,  supplier  partnerships,  and  other 
stakeholder  specifications.  It  is  not 
necessary  to  determine  how  these 
attributes  will  be  accomplished  as  that  is 
a  task  in  the  process  reengineering  phase. 

The  final  result  of  this  task  should  be  a  short 
statement  that  summarizes  the  process  vision.  It 
must  be  written  in  less  than  a  page  and  acceptable  to 
all  project  team  members  and  their  functional 
sponsors. 

4.5.8  Develop  Process  Improvement  Strategy. 

Once  the  process  vision  has  been  established,  the 
project  team  next  works  out  the  strategy  for 
realizing  the  process  vision.  The  strategy  includes  a 
series  of  actions  that  will  be  taken  once  the  project 
plan  is  approved.  If  the  process  vision  includes  the 
use  of  innovative  technology,  the  project  team 
should  develop  a  strategy  for  incorporating  this 
technology  in  the  process.  If  organizational 
enablers  are  need^  to  realize  the  process  vision,  the 
project  team  should  address  how  they  will  proceed 
to  make  these  organizational  changes.  The  strategy 
should  be  high-level  but  sufficient  for  functional 
managers  to  understand  the  general  approach  that 
will  be  made  in  the  process  improvement  project 
should  it  proceed  to  the  next  phase.  In  fact,  the 
statement  of  strategy  will  be  one  of  the  determinants 
of  project  continuation. 

4.5.9  Develop  the  Project  Plan.  Finally,  the 
project  plan  itself  is  constructed.  Everything  that 
has  been  done  to  this  point  in  the  methodology  and 
all  of  the  data  that  have  been  gathered  and  analyzed 
are  input  for  the  project  plan.  The  F/MPI  Project 
Manager’s  Guide  explains  in  detail  how  to  draft  the 
project  plan,  in  general,  it  should  include  the 
following  sections: 

■  Process  vision  including  objectives, 
attributes,  and  strategies 

■  Statement  of  purpose  describing  the 
intended  project,  brief  historical 
statement,  authority  for  the  project,  and  a 
summary  of  the  time  frame  and 
estimated  costs 
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■  Benefits  to  be  obtained  in  the  project  as 
they  relate  to  the  strategic  and  business 
plans,  stakeholders,  and  performance 
measures 

■  Critical  success  factors  for  the  project 

■  Project  scope  with  respect  to  the  DoD 
Enterprise  Model 

■  Work  breakdown  structure  showing  the 
major  tasks  to  be  completed 

■  Organizational  breakdown  structure 
showing  all  functional  participants 

■  Resource  assignment  matrix  showing 
how  the  tasks  in  the  work  breakdown 
structure  will  be  resourced 

■  Schedules  and  milestones  in  Critical  Path 
format 

■  Detailed  budgets  and  cost  estimates 

■  Resource  allocation  plan  including  labor, 
contract  requirements,  facilities,  and 
equipment 


■  Project  management  plan  showing  how 
the  project  will  be  managed,  how 
problems  and  issues  will  be  resolved,  the 
degree  of  project  communications  and 
status  reporting,  and  document 
management. 

The  project  management  plan  should  be  the 
basis  for  the  decision  to  proceed  with  the  project 
immediately,  delay  project  initiation,  or  cancel  the 
project.  It  should  be  written  in  a  way  that  facilitates 
that  decision  so  that  the  decision  itself  will  be 
acceptable  to  the  project  team  and  their  functional 
sponsors.  It  other  words,  the  project  plan  should  be 
a  true  representation  of  the  findings  and  analysis  of 
the  project  team  members.  The  project  team  may 
feel  that  a  briefing  package  should  be  developed  to 
communicate  the  results  of  the  project  team  and  ask 
for  a  specific  recommendation. 

4.5.10  Review  and  Approve  Project  Plan.  The 

project  plan  is  submitted  to  higher  authority  for 
review  and  approval.  In  some  cases,  the  review 
team  will  need  to  supply  clarification  or  conduct 
further  research  or  analysis.  For  this  reason,  the 
project  team  should  remain  in  place  until  the 
decision  is  made. 
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SECTION  5.  PHASE  2A:  BUSINESS  PROCESS  REENGINEERING 


Michael  Hammer  is  generally  acknowledged 
to  have  defined  the  concept  of  business  process 
reengineering’ .  He  counsels  that  the  rules  have 
changed  and  organizations  need  to  reconceptualize 
their  business  processes.  He  gives  several 
principles  for  doing  this: 

■  Organize  around  outcomes,  not  tasks. 
This  principle  overturns  the  concept  of 
division  of  labor,  which  was  the  basis  for 
the  factory  system. 

■  Have  those  who  use  the  output  of  the 
process  perform  the  process.  This 
principle  is  concerned  with  reducing  the 
internal  bureaucracy  within  an 
organization,  and  helping  external 
customers  do  more  for  themselves. 

■  Subsume  information  processing  work 
into  the  real  woric  that  produces  the 
information.  This  principle  is  embodied 
in  the  term  “end  user  computing.” 

■  Treat  geographically  dispersed  resources 
as  though  they  were  centralized.  This 
principle  supports  the  concept  of 
distributed  processing  and  client-server 
architectures. 

■  Link  parallel  activities  instead  of 
integrating  their  results.  This  principle 
supports  the  concept  of  concurrent 
engineering  where  work  teams  closely 
coordinate  with  each  other  throughout 
the  process. 

■  Put  the  decision  point  where  the  work  is 
performed  and  build  control  into  the 
process.  This  principle  encourages  the 
formation  of  self-directed,  empowered 


work  groups  and  flatter  management 
hierarchies. 

■  Capture  information  once  and  at  the 
source.  This  principle  supports  such 
technology  enablers  as  barcoding, 
electronic  data  interchange,  relational 
databases,  and  object-oriented 
application  code  development. 

While  it  is  possible  to  disagree  with  Hammer’s 
philosophy  and  recommended  methods  of  process 
reengineering,  virtually  all  of  his  principles  are 
supported  by  other  authorities  in  process 
reengineering.  In  essence.  Hammer  is  saying  is  that 
process  reengineering  is  radical  and  encourages 
process  improvement  teams  to  “think  big”  and  seek 
order-of-magnitude  increases  in  critical  process 
performance  measures. 

Thomas  H.  Davenport  suggests  that  American 
enterprises  need  to  combine  the  concept  of  radical 
reengineering  (Hammer)  with  the  discipline  of 
continuous  process  improvement  (TQM).‘®  He 
focuses  on  (he  use  of  technology  enablers  combined 
with  organizational  change  management  and 
suggests  that  the  project  management  concept 
(matrix  management)  is  the  way  to  achieve 
maximum  benefits  with  the  lowest  risk.  He  also 
encourages  the  inclusion  of  customers  (internal  and 
external)  in  process  reengineering  work  teams.  In 
general,  Davenport  recommends  a  more  stractured, 
controlled  (^(proach  to  process  reengineering  [than 
Hammer’s  radical  approach]  which  seems  more 
^>propriate  in  government  enterprises. 

H.  James  Harrington  stresses  that  before  an 
organization  can  q>proach  process  redesign,  it  first 
must  adopt  a  process  management  philosophy." 
Harrington  argues  more  for  the  concept  of  process 
redesign  (as  defined  in  this  guidebook)  rather  than 


9  “Reengineering  Work:  Don't  Automate,  Obliterate,”  Michael  Hammer,  Harvard  Business  Review,  July- August 
1990. 

10  Davenport,  Introduction. 

11  Business  Process  Improvement,  H.  James  Harrington,  ASQC  Quality  Press,  1991. 


Business  Process  Reengineering 


5-1 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


process  reengineering.  Harrington,  therefore,  is  an 
appropriate  reference  for  those  organizational  units 
striving  for  more  modest  gains  in  process 
improvement.  He  gives  ten  requisites  for  preparing 
for  process  improvement: 

1 .  The  organization  must  believe  that 
change  is  important  and  valuable  to  its 
future. 

2.  There  has  to  be  a  vision  that  paints  a 
picture  of  the  desired  future  state  that 
everyone  sees  and  understands. 

3.  Existing  and  potential  barriers  must  be 
identified  and  removed. 

4.  The  total  organization  must  support  the 
strategy  to  achieve  the  vision. 

5.  The  leaders  of  the  organization  need  to 
model  the  process  and  set  an  example. 

6.  Training  should  be  provided  for  the 
required  new  skills. 

7.  Measurement  systems  should  be 
established  so  that  results  can  be 
quantified. 

8.  Continuous  feedback  should  be  provided 
to  everyone. 

9.  Coaching  must  be  provided  to  correct 
undesired  behavior. 

10.  Recognition  and  reward  systems  must  be 
established  to  effectively  reinforce 
desired  behavior. 

Daniel  Morris  and  Joel  Brandon‘S  argue  that 
reengineering  methodologies  are  only  tools  that 
must  be  used  in  the  context  of  organizational 
change.  Their  concept,  called  Positioning, 
emphasizes  the  strategic  nature  of  organizational 
change.  Three  components  must  be  used  together 
to  effect  change: 


1 .  Positioning,  which  is  the  framework  for 
organizational  change 

2.  Traditional  project  management 
methods,  which  implement  the  change 

3.  Reengineering  techniques,  which  provide 
the  means  of  change. 

They  have  determined  that  there  are  seven 
critical  success  factors  for  process  reengineering: 

1 .  The  ability  to  conduct  reengineering  in 
accordance  with  a  comprehensive, 
systematic  methodology 

2.  Coordinated  management  of  change  for 
all  of  the  affected  business  functions 

3.  The  ability  to  assess,  plan,  and 
implement  change  on  a  continuing  basis 

4.  The  ability  to  analyze  the  full  impact  of 
proposed  changes 

5.  The  ability  to  model  and  simulate  the 
proposed  changes 

6.  The  ability  to  use  these  models  on  a 
continuing  basis 

7.  The  ability  to  associate  all  of  the 
management  parameters  of  the 
organization  with  each  other. 

There  are  other  authorities  on  process 
reengineering,  but  the  four  introduced  above 
together  seem  to  capture  the  essence  the  concept. 
Hammer  is  radical  and  visionary,  Davenport  is 
practical,  Harrington  is  cautious,  and  Morris  and 
Brandon  are  methodical.  This  points  up  the 
importance  of  selecting  an  appropriate  process 
manager  and  project  manager  for  improvement 
efforts.  In  the  final  analysis,  it  will  be  up  to  the 
leaders  of  change  to  fashion  the  nature  of  the 
improvement  project  and  the  means  to  bring 
it  about. 


12  Re-engineering  Your  Business,  Morris  and  Brandon,  McGraw-Hill,  1993. 
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This  phase  of  the  methodology  focuses 
primarily  on  the  reengineering  level  of  process 
improvement.  Please  refer  to  the  F/MPI  Process 
Reengineering  Tutorial  for  more  detailed 
information  on  how  to  approach  this  phase  of  the 
methodology. 

At  the  completion  of  this  phase,  the  process 
improvement  team  will  have  produced  a  Functional 
Economic  Analysis  (FEA)  management  decision 
package  that  presents  a  case  for  action.  The  FEA 
recommends  a  course  of  action  that  is  justified 
based  on  the  organization’s  planning  documents,  the 
analysis  of  the  current  situation  of  the  process  in 
question,  the  results  of  an  improvement  analysis, 
and  the  design  of  the  future  state  process.  The  FEA 
will  present  a  full  risk-adjusted  economic  analysis 
of  the  recommended  changes.  It  will  include  the 
elements  of  organizational  change  management 
needed  to  support  the  new  process  and  a  full 
evaluation  of  the  technology  enablers  that  are 
needed  to  implement  the  change.  The  FEA  is  one 
of  the  principle  inputs  to  the  next  phase  of  the 
methodology.  Enterprise  Engineering. 

The  process  reengineering  phase  of  the 
Framework  methodology  is  supported,  in  part,  with 
the  following  resources; 

■  F/MPI  Management  Briefing  on  Process 
Reengineering 

■  F/MPI  Process  Reengineering 
Assessment 

■  F/MPI  Process  Reengineering  Tutorial 

■  F/MPI  Process  Reengineering  Evaluation 
Worksheet 

■  Process  Improvement  Methodology  for 
DoD  Functional  Managers 

■  Functional  Economic  Analysis 
Guidebook 

■  Functional  Process  Simulation 
Guidebook 

■  Baseline  Workshop 

■  Preparing  For  and  Initiating  Functional 
Process  Improvement  (FPI)  Programs 
Guidebook. 


The  techniques  (described  in  Section  10)  most 
useful  in  this  phase  include  the  following: 

■  Brainstorming 

■  Nominal  Group  Technique 

■  Affinity  Diagrams 

■  Relationship  Diagrams 

■  Activity  Modeling 

■  Data  Modeling 

■  Activity-Based  Costing 

■  Pareto  Analysis 

■  Best  Practices  Benchmarking 

■  Simulation 

■  Economic  Analysis 

■  Program  Decision  Process  Chart 

■  Cause  and  Effect  Analysis 

■  Survey/Interview 

■  Checksheets. 

5.1  Step  6:  Conduct  Baseline  Analysis 

The  concept  of  process  is  relatively  new  and 
somewhat  troublesome  in  organizations  with  a 
strong  functional  management  structure.  Few 
people  in  such  organizations  truly  understand  the 
nature  of  their  end-to-end  processes.  Several  could 
not  precisely  describe  the  products  and  services 
produced  by  these  processes.  Many  are  not  even 
sure  who  the  process  customers  are  and  what  they 
require  of  the  process.  It  is  difficult  to  envision 
successful  process  improvement  in  such 
organizations  without  the  intermediating  step  of 
conducting  a  baseline  process  analysis. 

The  purpose  of  conducting  a  baseline  analysis 
is  to  establish  a  firm  foundation  from  which  to 
begin  the  improvement  effort.  In  many  cases,  this 
is  the  beginning  of  shifting  the  organization  from  a 
functional  management  concept  to  a  process 
management  concept.  The  goals  of  baseline 
analysis  (while  challenging  to  achieve)  are  clear  and 
straightforward: 

■  Rigorously  define  the  structure  of  a 
process  (or  subprocess)  in  terms  of  the 
activities  that  are  performed  in  the 
process,  the  outputs  they  produce,  the 
inputs  they  require,  the  resources  they 
consume,  and  the  standards  they  operate 
under. 
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■  Rigorously  define  the  data  elements 
required,  produced,  or  modified  by  the 
process  and  the  business  rules  inherent  in 
existing  data  structures. 

■  Understand  the  relationship  of  the 
process  to  each  functional  element  that 
participates  in  process  performance. 

■  Identify  and  characterize  the 
stakeholders  of  the  process  including 
customers,  suppliers,  higher  authority, 
and  resource  providers  and  determine 
their  relationship  to  the  process  in  terms 
of  quantifiable  measures. 

■  Clarify  exactly  how  the  process  works, 
not  how  process  participants  think  or 
believe  it  works. 

■  Determine  the  unit  costs  of  each  major 
output  produced  by  the  process.  (These 
are  called  cost  measures  in  this 
guidebook.) 

■  Determine  process  cycle  and  response 
times  with  respect  to  producing  desired 
output  products  and  services.  (These  are 
called  time  measures  in  this  guidebook.) 

■  Document  known  problems,  issues, 
deficiencies,  and  defects  with  respect  to 
organizational  structure,  process 
operation,  and  output  products  and 
services.  (These  are  collectively  called 
quality  measures  in  this  guidebook.) 

■  Document  the  status  of  the  technology 
elements  that  support  the  process 
computer  and  communications 
platforms,  networks,  data  bases, 
application  systems,  and  technical 
support  services.  (In  this  guidebook, 
these  technical  elements  will  collectively 
be  called  Information  Technology  (IT) 
when  referring  to  the  facilities 
themselves,  and  Information  Systems 
(IS)  when  referring  to  the  services 
delivered  to  the  process.) 


If  all  the  planning  steps  described  in  this 
guidebook  were  performed  prior  to  starting  the 
process  reengineering  phase,  much  of  the 
information  listed  above  will  available  in  whole  or 
in  part.  It  is  important  not  proceed  beyond  this  step 
until  this  information  is  as  complete  as  can 
reasonably  be  expected. 

When  this  step  is  complete,  the  process 
improvement  team  will  know  two  important  things 
about  the  process:  the  present  state  (baseline 
analysis)  and  the  future  state  (planning  objectives 
and  goals).  With  this  information,  the  remaining 
steps  and  phases  in  the  Framework  methodology 
win  provide  guidance  on  how  to  get  from  present 
state  to  future  state  in  the  most  expeditious  manner 
possible. 

The  following  tasks  are  performed  in  the 
baseline  analysis  step: 

■  Develop  or  confirm  the  project  scope 

■  Develop  or  review  and  revise  AS-IS 
Activity  Models 

■  Develop  or  review  and  revise  AS-IS  Data 
Models 

■  Perform  activity  based  costing 

■  Perform  time-line  analysis  (simulation) 

■  Document  the  baseline  condition 

■  Revise  performance  cell  descriptions 

■  Review  and  approve  baseline 
documentation. 

5.1,1  Develop/Confirm  Project  Scope.  In  a  large 
enterprise  like  the  Department  of  Defense,  major 
processes  can  extend  throughout  the  organization. 

It  is  seldom  feasible  to  attempt  to  perform  process 
improvement  on  such  an  extensive  basis.  This 
means  that  the  focus  of  improvement  efforts  will 
have  to  be  at  the  subprocess  level.  This  requires  a 
firm  understanding  of  the  scope  of  the  improvement 
project.  In  this  context,  the  term  scope  does  not 
refer  to  the  amount  of  improving  that  will  be 
attempted;  it  refers  instead  to  the  potential 
involvement  of  functional  units  in  the  improvement 
project. 
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The  most  important  techniques  for  setting  the 
scope  of  the  project  are  developing  or  confirming 
the  process  deployment  map  (or  matrix),  and  using 
the  IDEFO  context  diagram  technique  to  establish 
bounds  on  the  improvement  project.  The 
deployment  map  (Figure  5-1)  shows  the  functional 
elements  that  are  involved  with  a  process  and  the 
degree  of  their  participation.  The  context  diagram 
(Figure  5_2)  shows  the  boundary  conditions  of  the 
process  with  respect  to  inputs,  outputs,  controls  and 
mechanisms  (resources).  Each  of  these  lines  (input, 
output,  etc.)  is  connected  to  a  process  stakeholder. 
Please  refer  to  the  F/MPI  Process  Reengineering 
Tutorial  for  al  fuller  explanation  of  this  task  and  the 
following  tasks  of  this  step. 

As  shown  in  the  figures,  the  project  scope 
identifies  the  functional  elements  that  will 
participate  or  be  affected  by  the  improvement 
project  and  the  stakeholders  in  the  process.  These 
data  will  be  useful  in  establishing  performance 
measures  and  performance  goals  later  in  the 
methodology. 


This  task  as  well  as  the  other  tasks  in  this  step 
are  usually  performed  in  a  workshop  environment 
with  experienced  process  participants  and 
representation  from  key  stakeholders.  Once  the 
scope  of  the  improvement  project  is  established,  the 
next  four  tasks  develop  detailed  models  of  the 
baseline  process. 

5.1.2  Develop/Review/Revise  AS-IS  Activity 
Models.  During  the  first  iteration  of  process 
improvement,  it  is  not  likely  that  activity  models 
will  exist  for  the  process  scheduled  for 
improvement.  In  this  case,  activity  models  will  be 
developed  for  the  first  time  in  the  baseline 
workshop.  If  models  do  exist,  they  still  need  to  be 
reviewed  and  revised  as  necessary  to  reflect  the 
actual  status  of  the  process. 

Activity  models  are  developed  to  display 
business  activities  and  their  relationships.  When 
completed,  an  activity  model  represents  a  detailed 
understanding  of  how  the  process  works  and  how 
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information  and  physical  artifacts  ^ow  through  the 
process.  Activity  models  also  aid  considerably  in 
identifying  process  performance  measures  that 
reflect  stakeholder  interests. 

The  task  then  is  to  develop  a  fully 
decomposed  activity  model  using  the  process 
context  diagram  as  a  starting  point.  A  process  is 
fully  decomposed  when  the  resulting  levels  of 
activities  clearly  show  the  major  outputs  produced 
by  the  activities  in  the  process.  Node  trees,  which 
are  hierarchical  representations  of  the  activities  in  a 
process,  are  produced  before  the  decomposition 
process  is  begun. 

IDEFO  is  the  standard  activity  modeling 
technique  to  be  used  in  DoD  and  all  other  Federal 
agencies.  Process  improvement  team  members 
must  be  trained  in  IDEF  techniques  prior  to  or  in 
conjunction  with  a  process  improvement  effort.  For 
more  information  on  IDEFO  activity  modeling,  refer 
to  the  Process  Improvement  Methodology  for  DoD 
Functional  Managers  Guidebook  and  Section  10  in 
this  guide. 

5.1.3  Develop/Review/Revise  AS-IS  Data 
Models.  The  next  task  is  to  develop  a  data  model 
that  shows  the  stracture  and  relationship  of  the 
elements  of  data  that  support  the  business  process. 
While  an  enterprise  may  have  an  infinite  number  of 
business  activities,  which  themselves  may  be  highly 
dynamic,  the  enterprise  generally  has  only  one 
relatively  stable  base  of  data  to  support  those 
activities. 

For  instance,  once  the  data  elements  related  to 
employee  are  encoded  in  a  data  base,  these  data 
elements  may  be  used  in  a  great  number  of  different 
applications.  Furthermore,  data  about  employees 
such  as  name.  Social  Security  number,  address, 
grade,  etc.,  change  infrequently  or  not  at  all. 
Therefore,  a  well-constructed  data  base  serves  as  a 
strong  foundation  for  building  information  systems 
to  support  business  processes. 

Furthermore,  processes  are  integrated 
primarily  by  transferring  data  effectively  between 
and  among  them.  For  instance,  in  concurrent 
(integrated)  manufacturing  systems,  engineering 


and  production  are  integrated  via  a  shared  data  base 
of  commonly  used  data  elements. 

This  task  is  concerned  with  constructing  the 
data  models  that  represent  how  the  process  uses 
data — ^which  elements  of  data  it  creates,  references, 
changes,  and  deletes.  The  data  model  also 
inherently  contains  business  rules  that  act  as 
constraints  on  process  operations.  For  instance,  the 
structure  of  the  data  model  may  prevent  the  deletion 
of  a  customer  record  if  that  customer  has 
outstanding  invoices.  In  other  words,  the  rule  is 
that  before  a  customer  can  be  deleted  from  the  data 
base,  all  open  invoices  must  be  closed  out. 

Data  models  are  created  at  different  levels. 

The  higher-level  models  are  completed  by 
functional  process  improvement  team  members;  the 
more  detailed  models  are  completed  by  technical 
staff  working  from  the  higher-level  models.  Data 
models  then  become  an  effective  means  of 
communication  between  functional  and  technical 
people. 

IDEFIX  is  the  standard  data  modeling 
technique  to  be  used  in  DoD  and  all  other  Federal 
agencies.  Process  improvement  team  members 
must  be  trained  in  IDEF  techniques  prior  to  or  in 
conjunction  with  a  process  improvement  effort.  For 
more  information  on  IDEFIX  Activity  Modeling, 
refer  to  the  Process  Improvement  Methodology  for 
DoD  Functional  Managers  Guidebook  and  Section 
10  in  this  guide. 

5.1.4  Perform  Activity-Based  Costing.  The  next 
task  in  this  step  is  to  develop  a  cost  model  of  the 
process  under  study.  Activity-based  costing 
techniques  are  used  to  determine  approximately  the 
resources  it  takes  to  produce  a  specific  product  or 
unit  of  service.  With  respect  to  an  activity  model,  it 
is  said  that  outputs  consume  activities  and  activities 
consume  resources. 

For  instance,  if  an  activity  can  produce  100 
widgets  a  week,  then  producing  100  widgets  a  week 
consumes  the  entire  activity.  If  the  cost  of  the 
activity  is  $10,000  per  week  in  terms  of  labor  and 
facilities  charges,  the  activity  will  consume  $10,000 
to  produce  100  widgets.  The  unit  cost  of  each 
widget  is  then  $100  plus  materials.  If  this  seems 
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too  easy,  it  must  be  remembered  that  most  activities 
produce  many  different  kinds  of  products  and 
services,  and  have  many  different  categories  of 
overhead  or  indirect  labor  charges  associated  with 
them.  The  trick  is  to  understand  the  unit  costs 
(direct  and  indirect)  of  each  type  of  product  or 
service  produced. 

ABC  techniques  allow  the  process 
improvement  team  to  allocate  all  overhead  costs  to 
specific  products  and  services  that  benefit  from  or 
are  the  reason  (cost  driver)  for  the  overhead  costs. 

In  service-type  processes  as  opposed  to 
product  producing  processes,  process  costs  are 
caused  by  the  demands  of  the  customer  rather  than 
the  demands  associated  with  producing  tangible 
products.*^  For  this  reason,  ABC  techniques  are 
best  employed  in  service  organizations  after 
customer  requirements  and  demands  are  understood 
by  the  process  improvement  team. 

.Once  the  unit  costs  are  known  for  each 
product  and  service,  this  information  ian  be  used  as 
a  baseline  figure  for  process  improvements  that  will 
lower  the  unit  cost  of  outputs.  As  we  will  see,  unit 
costs  can  be  lowered  by  eliminating  non- valued 
added  activities,  applying  innovative  technologies, 
increasing  training  to  reduce  waste  and  rework, 
improving  the  quality  of  incoming  materials  to 
reduce  rejects  and  scrap,  and  by  many  other  means. 

Performing  an  activity-based  costing  study 
will  identify  the  sources  or  triggers  for  costs 
expended  within  a  process.  Cost  driver  analysis 
will  be  performed  during  the  next  step  in  the 
methodology — ^process  improvement  analysis. 
Additional  ABC  analysis  work  will  be 
recommended  during  the  process  redesign/ 
reengineering  step. 

For  more  information  on  activity-based 
costing  techniques,  refer  to  the  Process 
Improvement  Methodology  for  DoD  Functional 
Managers  Guidebook  and  Section  10  in  this  guide. 

5.1.5  Perform  Time-line  Analysis  (Simulation). 

While  knowing  the  current  unit  costs  of  a  process  is 


vital  baseline  information,  it  is  equally  important  to 
understand  the  baseline  cycle  times  for  a  process. 
Cycle-time  measures  show  how  long  it  takes  to 
produce  a  product  or  service  once  the  request  for 
that  product  or  service  has  been  triggered. 
Experience  has  shown  that  the  best  way  to  reduce 
process  costs  is  to  focus  on  reducing  process  cycle 
time.  Cycle  time  is  made  up  of  several  elements: 

■  Operations  time,  which  is  the  actual 
processing  or  machine  time  needed  to 
produce  an  output 

■  Delay  time,  which  is  the  time  work  sits 
in  queues  (in-baskets)  waiting  for 
attention  or  resources. 

■  Quality  rework  time,  which  is  the 
amount  of  time  spent  discovering  and 
fixing  problems  (rework  time  is  an 
overhead  that  has  to  be  distributed  to  all 
output  products.) 

■  Inspection  and  oversight  time,  which  is 
time  spent  ensuring  that  products  and 
processes  conform  to  standards  and 
requirements. 

Each  of  these  elements  of  time  is  a  contributor 
to  overall  process  cycle  time.  Each  element  of  time 
can  be  reduced  using  appropriate  techniques. 
Employing  technology  enablers  is  one  technique, 
increasing  training  time  is  another,  just-in-time 
inventory  and  work  flow  is  another,  and  eliminating 
unnecessary  directives  and  other  constraints  is 
another.  But  before  these  techniques  can  be 
applied,  it  is  necessary  to  understand  where  the  time 
now  goes  in  the  baseline  process. 

Simulation  techniques  are  used  to  determine 
baseline  cycle  time  and,  of  course,  to  test  potential 
improvements.  For  more  information  on 
simulation,  please  refer  to  the  Functional  Process 
Simulation  Guidebook.  Prior  to  using  the 
simulation  techniques  described  in  this  guidebook,  a 
well-constracted  activity  model  is  prerequisite. 

5.1.6  Document  Baseline  Condition.  Once  the 
modeling,  activity-based  costing,  and  cycle-time 


13  The  Design  of  Cost  Management  Systems,  Robin  Cooper  and  Robert  S.  Kaplan,  Prentice  Hall,  1991. 
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tasks  have  been  completed,  the  information 
generated  must  be  summarized  in  the  baseline 
report.  At  this  time,  everything  known  about  the 
process  is  organized  and  described.  It  is  critically 
important  to  include  data  that  are  not  directly 
contained  within  the  models.  Such  data  include 
quality  measures,  problems  and  issues  that  were 
noted  during  the  study;  stakeholder  concerns  and 
suggestions;  organizational  and  human  factors  that 
affect  process  performance  and  quality  of  work  life; 
and  any  other  data  that  can  be  useful  to  the  process 
improvement  team. 

Generally,  the  activity  and  data  modeling 
reports  form  the  basic  documentation  package,  and 
all  other  considerations  are  documented  in 
appendices  to  these  reports.  The  general  rule  is 
simple:  anything  that  can  be  of  potential  use  to  the 
improvement  team  should  be  included,  anything 
that  is  extraneous  to  this  purpose  should  be  omitted 
or  stored  separately  as  backup  documentation.  The 
objective  is  not  to  measure  the  value  of  the  report 
by  its  thickness,  but  by  its  useful  content. 

5.1.7  Revise  Performance  Cell  Descriptions.  If 

the  performance  cell  technique  was  used  in  the 
planning  phase  of  the  methodology,  this  is  a  good 
time  to  revisit  the  baseline  measures  that  were 
included  in  the  performance  cell  charts.  With  the 
additional  data  gathered  in  this  step,  the  baseline 
measures  can  be  validated  or  updated  to  reflect 
reality. 

It  may  also  be  necessary  to  update  the  targets 
in  the  performance  cells  if  the  current  targets  seem 
either  too  ambitious  or  too  insignificant  with  respect 
to  the  baseline  measures  obtained  in  this  step. 
Signifcant  changes  to  performance  targets  must  be 
highlighted  for  approval  by  the  process  owner(s). 
Updated  and  valid  performance  cells  provide  an 
important  input  to  process  improvement  efforts. 

5.1.8  Review  and  Approve  Baseline 
Documentation.  After  all  baseline  data  have  been 
assembled  and  reviewed  and  accepted  by  the 
process  improvement  team  members  and  their 
functional  sponsors,  it  is  submitted  to  the  process 
owner  or  other  higher  authority  for  review  and 
approval. 


As  stated  in  the  introduction  to  this  step,  the 
process  improvement  team  will  now  have  achieved 
two  important  accomplishments  at  this  point  in  the 
methodology:  a  description  of  the  desired  future 
state  for  the  process  produced  in  the  planning  phase, 
and  a  description  of  the  actual  present  state  of  the 
process  provided  in  this  step.  With  the  baseline 
described  and  the  future  state  objective  known,  all 
that  is  left  is  to  figure  out  how  to  get  from  here  to 
there.  The  rest  of  the  Framework  methodology  is 
dedicated  to  this  objective. 

5.2  Step  7:  Conduct  Improvement  Analysis 

At  this  point  in  the  methodology,  the  baseline 
situation  of  the  process  is  documented  and  its  future 
state  has  been  visualized.  This  step  is  concerned 
with  understanding,  quantifying,  and  documenting 
the  performance  gaps  separating  the  current  state 
from  the  future  state.  The  mission  of  this  step  is  to 
reconnoiter  the  territory  that  must  be  taken  without 
yet  engaging  the  enemy.  That  is,  understand  what 
must  be  done,  but  don’t  do  it  yet.  The  next  step  in 
the  methodology  is  concerned  with  designing  the 
program  that  will  close  the  performance  gaps  and 
bring  the  process  to  a  new  higher  level  of 
performance. 

This  step  prepares  the  process  improvement 
team  for  process  redesign  or  reengineering  by 
identifying  and  quantifying  the  existing  gaps  in 
satisfying  stakeholder  needs;  the  deficiencies  in 
quality,  cycle  time,  and  cost  factors;  and  the 
enablers  and  constraints  associated  with  process- 
related  organizational  and  technical  issues.  When 
these  factors  are  well-understood  prior  to  process 
redesign  or  reengineering,  the  risk  of  process 
improvement  effort  are  minimized. 

This  step  requires  the  application  of  process 
improvement  techniques  for  data  gathering  and 
objective  performance  gap  analysis.  The  data 
provided  by  the  application  of  techniques  establish 
a  basis  for  effective  workshop  participation  among 
the  improvement  team  members. 

This  results  of  this  step  will  also  help  the 
improvement  team  decide  whether  a  process 
redesign  (incremental  change)  effort  is  indicated  or 
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whether  a  process  reengineering  (radical  change) 
effort  is  indicated.  This  is  a  critical  decision 
because  process  redesign  projects  take  less  time  to 
complete  and  therefore  deliver  results  (process 
improvements)  faster  at  lower  cost  with  less  risk 
than  reengineering  projects.  The  results  of  this  step 
will  also  provide  meaningful  data  for  inclusion  in 
the  Functional  Economic  Analysis  (FEA)  package 
completed  at  the  end  of  the  process  reengineering 
phase.  The  FEA  package  will  be  the  basis  for  the 
management  decision  to  proceed  or  not  proceed 
with  the  recommended  process  improvement 
project. 

In  this  step,  the  process  improvement  team 
will  investigate  performance  gaps  in  the  following 
areas: 

■  Satisfying  external  customer  product/ 
service  needs  and  requirements 

■  Satisfying  other  stakeholder 
requirements  vis-k-vis  customer  needs 

■  Error  rates  associated  with  delivered 
products  and  services 

■  Delays  in  responding  to  customer  and 
other  stakeholder  requirements 

■  Asset  deployment  and  utilization 

■  Cross-functional  understanding  and 
cooperation 

■  Productivity 

■  Flow  of  work  throughout  the  process 
(workflow  management) 

■  Process  adaptability  and  flexibility  to 
respond  to  changing  requirements 

■  Excessive  resources  and  head  count 
(right-sizing). 

The  following  tasks  are  performed  in  the 
improvement  analysis  step: 

■  Review  process  vision,  objectives,  and 
measures 

■  Conduct  stakeholder  requirements  gap 
analysis 

■  Conduct  best  practices  benchmarking 
analysis 

■  Select  data  gathering  and  analysis 
techniques 

■  Identify  and  document  performance  gaps 
in  product  quality 


■  Identity  and  document  performance  gaps 
in  process  cycle  time 

■  Identify  and  document  performance  gaps 
in  process  cost 

■  Identify  and  document  process-related 
issues 

■  Identity  and  document  organizational 
issues 

■  Identify  and  document  technology  issues 

■  Develop  process  improvement 
opportunities 

■  Prepare  process  improvement  analysis 
report 

■  Review  and  approve  process 
improvement  analysis  report. 

5.2.1  Review  Process  Msion,  Objectives,  and 
Measures.  The  planning  phase  of  the  methodology 
produced  a  process  vision  that  incorporated  a  series 
of  breakthrough  improvement  objectives  supported 
by  the  identification  of  performance  measures.  This 
information  needs  to  be  reviewed  and  reaffirmed  by 
the  process  improvement  team  to  ensure  all  team 
members  have  a  clear  view  of  the  desired  future 
state  of  the  process.  At  this  time,  information  and 
insights  that  were  gained  during  the  baseline 
analysis  step  should  be  tested  against  the  future 
state  concept.  This  is  especially  true  with  regard  to 
measures.  The  more  well-defined  the  performance 
measures,  the  easier  it  is  to  conduct  a  performance 
gap  analysis. 

The  process  team  should  also  have  a  clear 
understanding  of  the  functional  objectives  as  they 
relate  to  process  objectives.  Functional  objectives 
make  up  the  control-chain  that  ensure  that  process 
performance  is  consistent  with  established  policy, 
directives,  guidance,  and  standards.  Any  functional 
objectives  that  may  affect  the  vision  of  the  future 
state  of  the  process  should  be  noted  and  investigated 
during  this  improvement  analysis  step. 

Finally,  the  process  owner  or  sponsor  should 
construct  a  series  of  challenges  that  have 
motivational  power  to  encourage  the  improvement 
team  to  uncover  all  process  and  functional  gaps  and 
factors  that  need  to  be  addressed  during  the  process 
redesign/reengineering  step  that  occurs  next.  The 
improvement  team  should  understand  what  areas 
related  to  process  performance  and  functional 
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Figure  5-3  Stakeholder/Process  Relationship 


organization  are  open  to  investigation  and  which 
areas,  if  any,  are  outside  the  bounds  of  the  study. 

5.2,2  Conduct  Stakeholder  Requirements 
Analysis.  To  complete  this  task,  the  improvement 
team  should  use  the  performance  cells  developed 
earlier  as  the  basis  for  conducting  an  investigation 
of  stakeholder  needs,  requirements,  interests,  and 
desires  as  they  relate  to  the  vision  of  the  improved 
process.  While  the  customer  stakeholder  needs  to 
be  the  focus  of  these  efforts,  successful  process 
improvement  projects  will  require  the  support  of  the 
other  process  stakeholders  as  well.  This  support  is 
obtained  more  readily  if  these  stakeholders  are 
included  in  the  performance  gap  analysis  step. 

The  relationship  of  a  stakeholder  to  a  process 
is  shown  in  Figure  5-3.  If  the  stakeholder  provides 
an  input  to  the  process,  feedback  measures  tell  the 
stakeholder  how  the  input  was  used.  If  the 
stakeholder  receives  an  output  from  a  process, 
feedback  measures  indicate  how  the  output  was 
used  by  the  stakeholder.  Measures,  it  will  be 
remembered,  are  grouped  into  four  categories: 
fitness-for-purpose,  conformance-to-standard, 
process  time,  and  process  cost. 

Because  there  is  an  expectation  on  the  part  of 
the  stakeholder  who  provides  a  process  input,  the 
process  improvement  team  must  know  what  that 
expectation  is,  and  whether  there  is  a  gap  between 
expectation  and  performance.  The  same  holds  true 
if  the  stakeholder  receives  an  output  from  the 
process.  Measures  are  the  means  to  determine  the 
existence  of,  and  extent  of,  the  gap.  The  process 
improvement  team  must  understand  any 


performance  gaps  in  terms  of  the  value-chain  from 
supplier  to  customer  and  the  control-chain  from 
higher  authority  to  resource  provider. 

During  process  redesign  or  reengineering  (the 
next  step),  improvement  teams  will  want  to  monitor 
whether  the  gaps  identified  in  this  step  increase  or 
decrease  based  on  the  proposed  changes  in  process 
performance.  This  is  where  a  firm  understanding  of 
value-chain  versus  control-chain  is  important. 

The  areas  of  investigation  are  included  in  the 
following  list: 

■  The  functionality,  usability,  and 
performance  of  process  inputs  and 
outputs 

■  The  reliability,  accuracy,  and  security  of 
process  inputs  and  outputs 

■  The  availability  (when  needed)  of  inputs 
and  outputs,  and  the  responsiveness  of 
the  process  in  handing  inputs  and  outputs 

■  The  degree  of  assurance  or  confidence 
the  stakeholder  has  in  the  process  and 
how  well  it  supports  stakeholder  interests 

■  The  degree  of  interest  and  empathy 
process  participants  have  in  working 
with  stakeholders,  and  the  degree  to 
which  process  participants  can  anticipate 
stakeholder  needs,  requirements,  and 
desires. 
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If  the  gaps  in  expected  versus  actual  process 
performance  in  these  areas  are  significantly  large, 
process  reengineering  may  be  called  for.  If  not,  it  is 
an  indication  that  process  redesign  or  streamlining 
may  be  sufficient  (at  lease  with  regard  to 
stakeholder  interests.)  The  improvement  team 
needs  to  understand  that  stakeholder  interests  are 
not  the  only  (and  perhaps  not  the  most  important) 
factor  in  deciding  how  radical  process  improvement 
efforts  should  be. 

5.2.3  Conduct  Best  Practices  Benchmarking 

Analysis.  With  the  understandings  gained  thus  far 
in  following  the  methodology,  the  process 
improvement  team  is  positioned  to  conduct  a  best 
practices  benchmark.  Unlike  the  strategic 
benchmark,  which  is  used  to  establish  performance 
targets  and  breakthrough  objectives,  the  best 
practices  benchmark  is  more  tactical.  It  is  designed 
to  discover  the  best  way  of  performing  a  process, 
subprocess,  or  group  of  activities.  In  other  words, 
the  strategic  benchmark  develops  the  process 
performance  goals;  the  best  practices  benchmark 
discovers  one  or  more  strategies  for,  or  means  of, 
attaining  the  goals. 

The  focus  of  a  best  practices  benchmark  is  on 
process  characteristics  as  well  as  the  organizational, 
culmral,  and  technical  enablers  that  support  the 
process.  This  task  produces  critical  data  that  can  be 
used  in  performance  gap  analysis  in  all  areas 
associated  with  the  process. 

Most  techniques  used  in  process  analysis  and 
design  are  relatively  easy  to  learn  and  use.  But  best 
practices  benchmarking,  if  it  is  to  be  effective, 
requires  that  process  teams  be  well-trained  prior  to 
embarking  on  the  benchmark  program.  The  period 
of  the  benchmark  program  may  extend  over  the 
remaining  tasks  in  this  step  and  well  into  the  tasks 
of  the  next  step.  There  are  many  advantages  to  this 
concurrency  and  some  disadvantages  as  well.  The 
project  leader  must  determine  whether  to  perform 
best  practices  benchmarking  in  series  or  in  parallel 
with  other  steps  and  tasks. 

5.2.4  Select  Data  Gathering  and  Analysis 
Techniques.  The  improvement  team  is  now 


prepared  to  launch  an  extensive  data  gathering  and 
analysis  program  in  support  of  the  remaining  tasks 
in  this  step.  The  process  improvement  team  should 
not  rely  100%  on  information  generated  in  the 
workshop  environment  to  understand  and  quantify 
performance  gap  data.  Much  of  this  type  of  data  is 
subjective  and  not  easy  to  verify.  Total  reliance  on 
subjective  data  increases  both  the  cost  of  an 
improvement  project  and  the  risk  of  failure.  Data 
should  be  gathered  from  all  sources  related  to  the 
process  and  using  all  available  performance 
measures.  The  results  of  this  off-line  effort  can  be 
effectively  used  back  in  the  workshop  to  stimulate 
further  analysis. 

There  are  well  over  30  recognized  techniques 
for  data  gathering  and  analysis.  Many  of  these 
are  briefly  described  in  Section  10  of  this  guide 
and  more  extensively  in  the  F/MPI  Process 
Improvement  Techniques  Tutorial.  The  following 
techniques  are  most  often  used  in  performance  gap 
analysis. 

■  Data  Gathering 

—  Survey  and  On-site  visits 
—  Interview  and  Focus  Groups 
—  Questionnaires  and  Assessments 
—  Brainstorming 
—  Checksheets 
—  Quality  Function  Deployment 
—  Benchmarking 

■  Data  Analysis 

—  Process  Deployment  Map 
—  Pareto  Diagrams 
—  Cause-and-Effect  Diagrams 
—  Affinity  Diagrams 
—  Process  Decision  Program  Charts 
—  (Quality  Function  Deployment. 

If  the  process  under  study  generates  sufficient 
and  reliable  operational  data,  statistical  process 
control  (SPC)  charts  and  techniques  can  be  used  to 
determine  the  degree  of  stability  in  the  process.  The 
results  can  be  analyzed  using  histograms,  bar  charts, 
and  other  analytical  techniques.  It  should  be  noted 
that  a  minimum  of  30  days’  worth  of  data  is  usually 
required  when  using  SPC  techniques. 
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5.2.5  Identify  and  Document  Performance  Gaps 
in  Product  Quality.  Process  attributes  related  to 
developing  high-quality  products  and  services 
should  be  the  focus  of  all  process  improvement 
efforts.  Therefore,  identifying  and  quantifying 
performance  gaps  in  quality-related  areas  are 
critical.  Failures  in  quality  may  be  felt  externally, 
which  means  that  customers  are  not  being  satisfied 
(among  other  things),  and/or  they  may  be  felt 
internal  to  the  process,  which  invariably  means  that 
process  costs  are  excessive.  There  is  substantial 
proof  that  while  quality  costs,  poor  quality  costs 
more. 

Performance  gap  analysis  should  include 
investigation  of  the  following  factors  with  respect  to 
output  products  and  services.  Once  again, 
excessive  performance  gaps  may  indicate  the  need 
to  consider  radical  process  reengineering,  especially 
if  benchmarking  results  show  that  other 
organizations  are  doing  much  better. 

■  Unacceptable  products  and  services 
—  Returns 

—  Rejects 
—  Loss  of  customers 

■  Too  much  time  spent  redoing  work 

■  Customer  complaints 
—  Phone  calls 

—  Letters  to  higher  authority 
—  Adverse  public  comments  or 
publicity 

■  High  warranty  costs  or  service  call-backs 

■  Excessive  meeting  time  devoted  to 
problem/issue  resolution 

■  Low  morale  or  high  personnel  turnover. 

5.2.6  Identity  and  Document  Performance  Gaps 
in  Process  Cycle  Time.  Experience  has  shown  that 
reducing  process  time  factors  will  always  result 

in  reducing  process  costs.  Therefore,  it  is  also 
critically  important  to  perform  a  thorough  gap 
analysis  in  this  performance  area.  Process  time  is 
the  aggregate  of  operations  time,  delay  time, 
overhead  time,  and  quality-related  time,  as 
defined  in  Section  2  of  this  guide. 

The  measures  to  study  include  the 
following: 


■  Cycle  time  per  unit  of  output  or  per 
transaction 

■  Wait  time  per  unit  of  output  or  per 
transaction 

■  The  ratio  of  direct  labor  hours  to  total 
hours 

■  Quality-rework  time 

■  Time  allocated  to  non-value  added 
activities 

■  Time  allocated  to  satisfying  controls 
placed  by  higher  authority 

■  Value-chain  versus  control-chain  time 
allocations 

■  Response  time  from  request  for  service 
to  service  delivery 

■  Ratio  of  operations  time  to  calendar  time 

■  Workflow  through  the  process  (relative 
location  of  work  centers) 

■  Serial  versus  parallel  processing  of 
transactions 

■  Interruptions  in  employee  work  time  for 
non- value  added  activities 

■  Method  of  setting  work  priorities 

■  Supplier-process  relationship. 

Many  of  the  performance  gaps  uncovered  in 
this  task  will  need  to  be  subjected  to  cause-and- 
effect  analysis  because  experience  has  shown  that 
process  delays  are  often  caused  by  problems 
upstream  of  the  process.  This  is  the  basis  of 
instituting  just-in-time  methods  of  material 
movement. 

5.2.7  Identify  and  Document  Performance  Gaps 
in  Process  Cost.  Process  costs  should  never  be  the 
direct  focus  of  performance  gap  analysis.  This  is 
because  all  process  costs  are  directly  related  to  other 
process  factors.  To  reduce  process  costs,  these 
other  factors  will  have  to  be  investigated.  The 
direct  contributors  to  process  costs  are  excessive 
process  cycle  time,  poor  product  and  service 
quality,  insufficient  information  about  customer 
requirements,  poor  supplier  relationships,  and 
unneeded  or  inappropriate  controls  placed  on 
processes  by  higher  authority  (excessive 
regulation). 

Poor  process  cycle  time  itself  is  caused  by 
excessive  overhead,  obsolete  technology,  poor  work 
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methods,  and  poorly  trained  personnel.  Poor 
product  and  service  quality  has  many  causes,  each 
of  which  has  to  be  investigated  as  recommended 
above.  Poor  supplier  relationships  result  when 
suppliers  are  not  treated  as  partners  with  respect  to 
servicing  customer  requirements.  Inappropriate 
controls  placed  by  higher  authority  are  often  the 
result  of  failing  to  review  controls  in  the  light  of 
changes  in  the  way  processes  are  conducted. 

Some  cost-related  performance  gaps  should  be 
studied  directly.  These  include  non-process  and 
non-product  related  expenditures  including  non¬ 
productive  facilities,  excessive  frills  and  perks; 
unnecessary  travel  and  living  expenses;  bloated 
staffing  levels;  and  losses  due  to  waste,  fraud,  and 
abuse. 

5.2.8  Identify  and  Document  Process-related 
Issues.  The  tasks  outlined  above  in  this  step  focus 
the  process  improvement  team  on  specific 
measures.  In  this  task,  the  team  will  analyze  the 
process  as  a  whole  with  respect  to  the  way  it 
satisfies  stakeholder  interests. 

This  is  the  right  time  to  continue  with  ABC 
analysis  to  investigate  and  understand  the  sources  of 
process  costs  (cost  drivers).  Cost  drivers  are  often  a 
mix  of  quality,  cycle  time,  and  cost  measures  and 
they  should  be  studied  as  a  whole.  However,  cost 
drivers  are  often  outside  the  process,  and  the 
tendency  of  the  process  improvement  team  is  not  to 
work  outside  the  scope  or  boundary  of  the  process. 
The  project  leader  must  insist  that  all  cost  drivers  be 
investigated  and  must  insist  that  the  results  of  the 
study  be  considered  in  the  improvement  analysis.  If 
this  is  not  done,  the  improvement  team  runs  of  the 
risk  of  suboptimizing  process  performance  and 
adding  to,  rather  than  deleting,  process  costs. 

The  questions  to  be  asked  include  the 
following  (with  respect  to  each  class  of 
stakeholder:) 

■  Who  receives  process  outputs  (or 
provides  process  inputs?) 

■  What  do  they  expect  from  the  process? 

■  How  do  they  use  the  output  (provide  the 
input)? 


■  What  impact  does  it  have  if  inputs  or 
outputs  are  wrong  or  inappropriate? 

■  How  is  feedback  on  output  (input) 
factors  generated? 

■  How  far  beyond  the  primary  stakeholders 
will  errors  have  an  impact? 

■  How  well  can  the  process  adapt  to 
changing  stakeholder  requirements? 

This  is  now  the  time  to  take  a  walk  through  the 
process  with  major  stakeholders  to  ensure  that  the 
process  as  a  whole  is  well  understood  before 
changes  in  the  process  are  designed.  Some  of  the 
areas  of  investigation  include  the  following: 

■  Procedures  used  within  the  process 

■  Documentation  used  to  control  or 
support  process  activities 

■  Training  programs  related  to  process 
requirements 

■  Techniques,  tools,  equipment,  and 
support  services  used  within  the  process 

■  Facilities  with  respect  to  how  they  enable 
or  constrain  process  performance 

■  Location  of  work  centers  related  to 
location  of  stakeholders 

■  Means  of  communication  used  within  the 
process 

■  How  stakeholder  interactions  are 
performed,  monitored,  and  evaluated 

■  Quality  and  accessibility  of  records  and 
data  needed  to  support  the  process. 

At  this  point,  it  becomes  possible  to  start 
thinking  of  the  process  under  study  in  terms  of 
subprocesses  and  groups  of  related  activities.  By 
the  time  the  remaining  tasks  in  this  step  are 
completed,  each  identifiable  subprocess  will  be 
placed  in  one  of  five  classifications.  All  data 
collected  and  analyzed  from  this  point  on  should  be 
used  to  aid  in  this  determination. 

The  five  classifications  for  subprocesses  are: 

■  Discontinue  or  disband  the  subprocess 

■  Take  no  further  action  on  the  subprocess 
(leave  it  alone) 

■  Designate  the  subprocess  as  a  candidate 
for  continuous  improvement 


Business  Process  Reengineering 


5-13 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


■  Designate  the  subprocess  as  a  candidate 
for  process  redesign 

■  Designate  the  subprocess  as  a  candidate 
for  process  reengineering 

5.2.9  Identity  and  Document  Organizational 
Issues  and  Barriers.  Process  improvement  is  not  a 
meaningful  term  apart  from  organizational  change 
management.  Organizational  change  management 
is  dealt  with  as  a  separate  phase  of  the  process 
improvement  methodology  (phase  2B  in  Figure  3- 
1).  At  this  time,  the  process  improvement  team  can 
begin  to  identify  problems,  issues,  potential  barriers 
to  change,  and  suggestions  for  organizational 
improvement  that  can  be  passed  on  to  phase  2B. 
This  should  be  done  now,  while  the  improvement 
team  has  a  fresh  understanding  of  process-related 
performance  issues  and  gaps.  This  study  will  aid  in 
the  process  classification  recommendation 
introduced  in  the  previous  task. 

The  following  12  sets  of  questions  asked  and 
answered  will  help  the  team  identify  organizational 
issues  and  barriers.  It  is  important  not  to  try  to 
resolve  these  issues  at  this  point.  This  action  will 
be  taken  after  all  the  facts  are  discovered  and 
investigated,  and  analyzed.  The  following 
questions  are  developed  from  Clemmer’s  book. 
Firing  on  All  Cylinders}* 

1 .  What  is  the  level  of  commitment  to 
improvement  within  the  functional  units, 
and  how  is  leadership  manifested? 

2.  To  what  extent  are  customer  needs, 
requirements,  and  desires  used  to  shape 
functional  unit  activities  and  priorities? 

3.  How  well  do  employees  understand  the 
mission  of  the  organization,  and  are 
education  and  training  programs  oriented 
toward  increasing  employee  awareness 
of  the  importance  of  serving  customer 
interests? 


4.  How  do  functional  units  hire,  orient, 
develop,  promote,  and  support 
employees  with  respect  to  process 
requirements? 

5.  What  personal  skills  are  valued  within 
functional  units  and  how  are  those  skills 
developed  and  rewarded?  How  well  is 
skill  development  related  to  supporting 
the  value-chain  within  the  process? 

6.  Are  managers  and  supervisors  trained  in 
coaching  skills,  and  are  those  skills 
focused  on  developing  a  high- 
performance  unit  fostering  improvement 
and  innovation? 

7.  To  what  extent  is  the  functional  unit 
developing  team  skills  such  as  the 
effective  use  of  techniques  and  tools, 
process  management,  problem  solving, 
meeting/workshop  management,  and 
interpersonal  skills? 

8.  How  well  are  the  human  resource 
systems  aligned  with  process 
performance  requirements  including 
supplier  management,  information 
management,  and  customer  support? 
What  are  the  relationships  with  respect  to 
rank,  responsibility,  authority,  and 
accountability?  How  prevalent  are 
bureaucratic  in-fighting  and  turf  wars? 

9.  What  are  the  recognition  and  reward 
systems  and  how  are  they  aligned  with 
work  team  practices,  empowerment, 
customer  service  needs,  and  cross¬ 
functional  cooperation?  Is  there  an 
excess  of  feel-good  rewards  and  not 
enough  rewards  for  effective 
performance  in  support  of  mission 
requirements? 

10.  How  well  established  are  process 
management  principles?  Are  there 
process  owners  in  place  for  all  major 
processes  and  subprocesses?  Are  quality 


14  Firing  on  All  Cylinders,  Jim  Clemmer,  Business  One  Irwin,  1992. 
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and  process  improvement  teams  in 
place?  Are  roles  and  responsibilities 
aligned  with  mission  and  customer 
requirements?  Are  continuous  process 
improvement  principles  implemented? 

1 1 .  Are  processes  managed  based  on 
performance  measures?  Are  measures 
related  to  delivering  customer 
satisfaction?  Are  all  important  elements 
of  process  performance  measured?  Are 
results  continuously  provided  to  process 
and  improvement  teams?  Are  all 
stakeholder  interests  related  to 
performance  and  feedback  measures? 

Are  there  systems  in  place  to  monitor, 
manage,  and  improve  product  and 
service  quality?  Is  benchmarking 
established  as  a  management  practice? 
Are  performance  standards  meaningful? 

12.  Is  there  a  continuing  program  in  place  to 
identify  and  serve  customer  interests? 

Do  process  participants  look  for 
opportunities  to  develop  new  internal  and 
external  customers?  Are  customers 
really  in  charge  of  the  process  with 
respect  to  designing  products  and 
services  and  setting  process  priorities? 

Negative  answers  to  these  questions  indicate 
that  organizational  change  management  will  be  a 
major,  if  not  the  major,  focus  of  process 
improvement.  As  stated  in  Section  2  of  this  guide, 
process  improvement  cannot  exist  in  any 
meaningful  way  apart  from  the  principles  of  process 
management.  Process  management  is  an 
organizational  issue. 

5.2.10  Identify  and  Document  Technology 
Issues.  Technology  is  both  an  enabler  of  change 
and  a  constrain  on  change.  Enablers  come  from 
innovative  uses  of  new  technologies,  while 
inhibitors  are  the  result  of  the  presence  of  legacy 
systems.  Phase  2C  of  the  methodology  deals  with 
technology  change  management.  This  task  is 
concerned  with  uncovering  technology-related 
issues  that  need  to  be  investigated  and  analyzed 


with  respect  to  process  management  and 
improvement.  There  should  be  no  attempt  in  this 
task  to  resolve  technology  issues,  only  to  identify 
them. 

As  with  organizational  barriers,  an  effective 
way  to  discover  technology-related  issues  is  to  ask 
and  answer  a  series  of  questions.  Until  recently, 
technology  and  information  management  systems 
modeled  the  organizational  hierarchy  and  as  such 
was  part  of  the  problem  with  respect  to  adopting  a 
process  management  orientation.  The  technology 
paradigm  shift  to  networks,  client-server 
architectures,  distributed  data  bases,  work  group 
computing,  etc.  actually  is  an  enabler  of  process 
management  and  a  major  contributor  to  the 
breakdown  in  the  hierarchical  management  model.*’ 
The  following  questions  are  developed  from 
Tapscott  and  Gaston’s  book.  The  answers  to  these 
questions  will  tell  a  lot  about  the  attitudes  within  the 
functional  units.  The  attitudes  will  be  a  good 
indication  of  the  probable  success  of  any  significant 
improvement  effort,  and  most  certainly  one  based 
on  technology  enablement. 

1 .  To  what  degree  are  information  systems 
open?  Do  suppliers  and  customers  have 
access  to  process  related  data  that  affect 
their  involvement  in  the  process 
(interoperable  systems)?  Can 
information  systems  be  ported  to 
different  hardware  platforms? 

2.  Are  systems  functionally  integrated  to 
support  process  management 
requirements?  Are  communications 
networks  being  used  to  interconnect 
work  teams  wherever  they  are  located? 

3.  Are  distributed  computing  systems  being 
put  in  place  to  help  empower  workers 
and  work  teams  to  serve  customer 
requirements  effectively  and  efficiently? 
Is  intelligence,  not  just  data,  being  made 
easily  available  to  work  teams  so  support 
immediate  decision-making  with  respect 
to  customer  requests  for  service  and 
products? 


14  Paradigm  Shift,  the  New  Promise  of  Informaiton  Technology,  Don  Tapscott  and  Art  Gaston,  McGraw-Hill,  1993. 
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4.  Are  data  collected  on  a  real-time  basis  at 
the  source  and  distributed  to  where  they 
eu'e  needed?  Are  just-tin-time  practices 
being  put  in  place  for  information 
systems?  Are  information  systems 
designed  to  allow  processes  to  easily 
adapt  to  changing  supplier  and  customer 
relationships? 

5.  Are  client-server  systems  being  put  in 
place  to  support  cross-functional  process 
requirements  and  design  more  efficient 
work  flows? 

6.  Are  peer-to-peer  networks  replacing 
mainframe-dumb  terminal  platforms 
wherever  possible  to  support  the  notion 
of  an  enterprise  being  based  on 
commitment  rather  than  control, 
accomplishment  rather  than 
accountability,  customer  service  rather 
than  serving  the  hierarchy? 

7.  Are  information  systems  being  develop 
according  to  modular  concepts  that 
support  organizational  independence, 
resulting  in  a  flexible,  adaptable 
enterprise?  Are  standardized,  reuse,  or 
object-oriented  application  modules 
being  developed  that  can  be  reconfigured 
to  serve  changing  needs? 

8.  Are  systems  being  developed  to 
specifically  support  the  needs  of 
knowledge  workers  rather  than  the  needs 
of  clerical  workers?  Are  specialized 
platforms  being  installed  to  support 
specialized  needs  such  as  computer- 
aided  design  and  drafting  systems,  rule- 
based  decision  making  (expert  systems), 
multimedia  applications,  and  team-based 
requirements? 

9.  Are  user-friendly  graphical  interfaces 
being  designed  into  all  systems  to  permit 
access  to  a  wide-library  of  information 
services  and  systems  without  the  need  to 
learn  a  large  number  of  specialized 
interfaces?  Does  the  organization  seek 
to  maximize  or  limit  the  distribution  of 


information  technology  and  information 
systems?  Is  computing  power  being 
placed  first  with  those  who  directly 
support  customers,  or  are  back-office 
operations  given  preference? 

10.  Are  wide  area  networks  being  put  in 
place  to  support  stakeholders  and 
employees  wherever  they  may  be 
located?  Can  teams  easily  form  and 
work  together  based  on  availability, 
expertise,  and  knowledge  rather  than  on 
physical  location  or  proximity  to 
stakeholders? 

In  evaluating  the  answers  to  these  questions, 
improvement  teams  should  look  for  indications  that 
functional  management  is  receptive  to  change. 
Problems  are  indicated  when  the  answers  are  mostly 
negative,  and  managers  are  satisfied  with  the  status 
quo.  This  will  be  a  signal  to  the  improvement  team 
that  process  reengineering  efforts  may  not  be 
practical  at  this  time,  and  improvement  efforts  may 
have  to  be  limited  to  process  streamlining  and 
redesign. 

5.2.11  Develop  Process  Improvement 
Opportunities.  By  the  time  this  task  is  reached, 
process  improvement  teams  will  have  a  good 
understanding  of  the  opportunities  for  improvement 
that  should  be  addressed  in  the  next  step.  They  will 
also  be  able  to  classify  subprocesses  as 
recommended  in  task  5.2.8.  The  following  list  can 
be  used  as  a  guide  in  organizing  opportunities.  All 
of  the  data  collected  and  analyzed  in  previous  tasks, 
steps  and  phases  should  be  used  to  complete  this 
task. 

Because  there  will  be  redundancies  in  any 
such  list,  nominal  group  and  data  analysis 
techniques  should  be  used  properly  to  organize  and 
group  Aese  opportunities.  All  opportunities  should 
be  accompanied  by  performance  targets  whenever 
possible.  The  performance  cell  techniques  can  be 
used  to  guide  the  effort  to  quantify  potential 
improvements.  This  task  is  best  completed  in  the 
workshop  environment. 

The  improvement  team  should  list 
opportunities  to: 
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■  Improve  customer  service  by  eliminating 
problems  and  complaints 

■  Improve  product/service  quality  by 
eliminating  errors  and  rejects 

■  Strengthen  the  value-chain  by 
minimizing  non-value  added  activities 

■  Adjust  the  control-chain  by  eliminating 
inappropriate  controls 

■  Reduce  process  cycle  time  (operations, 
wait,  overhead,  quality) 

■  Lower  process  costs  (fixed  and  variable) 

■  Add  new  services  and  products 

■  Close  performance  gaps  in  baseline-to- 
target  measures 

■  Emulate  best  practices  found  during 
benchmaricing  activities 

■  Develop  knowledge-based  systems  for 
front-line  workers 

■  Improve  workflows  within  processes  by 
realigning  facilities  and  equipment 

■  Make  processes  more  flexible  and 
adaptable  to  changing  conditions 

■  Exploit  new  technologies  (see  previous 
task) 

■  Satisfy  management  imperatives 
(mission,  objectives,  and  goals) 

■  Develop  new  supplier  partnerships  for 
just-in-time  service  and  lower  costs 

■  Improve  work  place  health,  safety, 
morale,  and  job  satisfaction 

■  Balance  accessibility  and  security 
requirements 


■  Lower  risks  of  process  failure  and 
increase  process  stability 

■  Realign  organizational  structures  to 
support  process  management  principles 

■  Improve  training  methods  in  support  of 
competency-based  principles 

■  Reduce  paper  work,  flows,  and  storage 
requirements 

■  Develop  in-process  performance 
measures  for  continuous  process 
improvement 

■  Maximize  resource  and  asset  utilization 

■  Streamline  and  flatten  organizational 
units  and  reduce  unnecessary  headcount 

■  Standardize  around  open  systems 
architectures 

■  Eliminate  and  replace  obsolete  or 
expensive  legacy  systems 

5.2.12  Prepare  Process  Improvement  Analysis 
Report.  The  process  improvement  analysis  report 
and  recommendations  can  now  be  prepared.  The 
focus  of  the  report  should  be  on  process, 
subprocesses,  and  groups  of  related  activities.  Each 
subprocess  should  be  assigned  to  one  of  the  five 
classifications  described  in  Section  5.3.8  and 
specific  recommendation  should  be  given  for  each 
subprocess  with  respect  to  that  classification. 

To  the  extent  feasible,  the  following  factors 
should  be  included  for  each  recommendation  based 
on  the  data  gathered  during  the  tasks  in  this  step. 
The  team  does  not  need  to  expend  time  and 
resources  developing  these  data  if  they  are  not 
readily  available.  The  purpose  of  including  these 
data  is  to  enable  higher  authority  to  better 
understand  the  potential  impact  of  designing 
solutions  for  these  opportunities. 

■  Estimate  of  resources  needed  to  exploit 
the  opportunity 

■  Estimated  return  on  investment  of  these 
resources 
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■  Known  risks  resulting  from  the 
improvement  analysis 

■  Potential  benefits  of  implementing  the 
recommended  opportunity. 

5.2.13  Review  and  Approve  Process 
Improvement  Analysis  Report.  The  improvement 
analysis  report  is  submitted  to  higher  authority  for 
review  and  approval.  In  some  cases,  the  review 
team  will  need  clarification  or  further  investigation. 
For  this  reason,  the  project  team  should  remain  in 
place  until  the  final  decision  is  made. 

5.3  Step  8:  Redesign/Reengineer  Processes 

Up  to  this  point,  data  supporting  process 
improvement  have  been  gathered  primarily  using 
andytical  techniques.  Methods,  procedures,  and 
rules  are  well-suited  to  helping  improvement  teams 
break  things  into  their  component  parts.  Now  in 
this  step,  it  is  necessary  to  build  up  those  parts  into 
redesigned  or  reengineered  processes.  This  requires 
a  shift  in  thinking  from  analysis  to  synthesis. 
Synthesis  is  a  creative  endeavor.  There  are  fewer 
rules  to  support  creative  thinking,  which  is  a 
characteristic  of  design  activities — guidelines  will 
have  to  suffice. 

Figure  5-4  provides  a  high-level  overview  of 
the  redesign  effort,  which  will  result  in  one  or  more 
recommended  improvement  packages  that  will  be 
structured  into  a  complete  business  case  in  the  next 
step.  Previous  steps  have  produced  one  or  more 
processes  for  redesign  or  reengineering,  the  process 
vision  and  target  performance  measures,  and  a  set  of 
opportunities  for  improvement. 

The  first  task  in  process  redesign  is  formulate 
one  or  more  improvement  initiatives.  An  initiative 
is  a  design  specification  that  identifies  the  scope  of 
the  design  effort,  process  boundaries,  level  of 
improvement,  design  objectives,  performance 
targets,  and  opportunities  that  will  be  considered 
during  the  design  effort. 

The  process  redesign/reengineering  task 
selects  or  specifies  organizational  and  technology 
enablers,  identifies  process  improvement  strategies, 
and  employs  creative  thinking  to  produce  a  design 
package  for  the  improved  process.  The  design 


package  consists  of  TO-BE  activity  and  data  models 
along  with  narratives,  charts,  measures  and  other 
data  that  capture  the  design  features  of  the  renewed 
process.  Organizational  enablers  are  provided  in 
phase  2B  of  the  methodology;  Technology  enablers, 
in  phase  2C. 

There  are  often  several  alternatives  for 
implementing  a  design  package,  usually  based  on 
which  organizational  and  technology  enablers  are 
selected  to  support  the  new  process  design.  For 
instance,  when  AT&T  was  designing  its  Universal 
Credit  Card  customer  enrollment  process,  either 
dumb  terminals  or  networked  personal  computers 
could  be  provided  to  service  representatives.  They 
initially  chose  dumb  terminals  but  later  replaced 
them  with  intelligent  work  stations  as  part  of  a 
process  reengineering  effort. 

Alternatives  always  have  economic 
implications,  which  is  why  a  preliminary  economic 
andysis  is  performed  during  this  step.  In  the  next 
step  of  the  methodology,  a  full  economic  analysis 
will  be  performed  when  constructing  the  Functional 
Economic  Analysis  (FEA)  decision  package. 

As  the  appropriate  point  in  the  design  process, 
the  process  improvement  team  should  initiate 
activities  with  data  administration  and  the  technical 
staff  for  information  systems.  These  groups  will 
need  to  furnish  technical  data  in  support  of  the  FEA. 

Process  improvement  team  members  should 
read  the  F/MPI  Tutorials  on  Organizational  Change 
Management  and  Technology  Change  Management 
before  proceeding  with  this  step. 

The  following  tasks  are  performed  in  the 
improvement  analysis  step: 

■  Review  process  improvement  analysis 
report 

■  Refine  process  vision  statement 

■  Develop  initiatives  for  process 
improvement 

■  Redesign/redevelop  business  processes 

■  Refine/redevelop  process  deployment 
map 

■  Describe  and  quantify  new  stakeholder 
relationships 
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Figure  5-4.  Process  Reengineering  Tasks 


■  Revise  future  state  performance  cell 
descriptions 

■  Validate  initiatives  and  models  against 
requirements 

■  Select  alternatives  for  process 
improvement  actions 

■  Perform  economic  analysis  on 
alternatives 

■  Develop  detailed  TO-BE  activity  and 
data  models 

■  Initiate/coordinate  data  administration 
activities 

■  Initiate/coordinate  information  systems 
activities 


■  Prepare  final  process  design 
specifications 

■  Review  and  approve  process  design 
specifications. 

5.3.1  Review  Process  Improvement  Analysis 
Report.  The  first  task  in  the  redesign  effort  is  to 
thoroughly  review  the  results  obtained  in  the 
previous  steps  of  the  methodology.  The  planning 
phase  produced  the  vision,  objectives,  and 
performance  measures;  the  baseline  analysis  step  in 
this  phase  documented  the  current  state  of  business 
processes;  and  the  improvement  analysis  step 
produced  opportunities  for  improvement.  The 
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process  improvement  team  is  now  positioned  to 
design  or  reengineer  the  selected  business  processes 
or  subprocesses. 

5.3.2  Refine  Process  Vision  Statement.  The 
process  vision  statement  is  the  keystone  of  process 
improvement.  It  helps  process  improvement  teams 
stay  focused  on  the  expected  outcomes  of  process 
improvement  and  not  get  lost  in  the  details.  At  this 
time  it  is  necessary  to  revisit  the  vision  statement 
and  ensure  that  it  is  still  valid  as  a  guide  to  redesign 
efforts.  Process  performance  cells  should  also  be 
reviewed  to  ensure  that  the  specific  performance 
targets  are  still  attainable.  Finally,  the  strategic  and 
business  plans  that  apply  to  the  processes  under 
improvement  should  also  be  reviewed  to  ensure  that 
business  objectives  and  goals  are  properly 
considered  during  the  design  effort. 

5.3.3  Develop  Initiatives  for  Process 
Improvement.  The  previous  step  developed  a 
multitude  of  process  improvement  opportunities — 
some  based  on  process  problems,  some  on 
identified  stakeholder  requirements,  and  some  on 
business  objectives  contained  in  strategic  and 
business  plans.  Unless  the  list  of  improvement  is 
quite  smdl,  it  is  seldom  practical  to  attempt  to 
address  all  of  them  in  one  design  effort.  Therefore, 
the  process  improvement  team  should  develop  one 
or  more  improvement  initiatives  that  represent  a 
unit  or  package  of  improvement  specifications. 

This  concept  also  serves  as  a  means  of  performing 
segments  of  improvement  projects  in  parallel, 
which  can  dramatically  reduce  the  overall  calendar 
time  needed  to  complete  improvement  efforts. 

Each  package  will  address  a  bounded  process 
or  subprocess,  a  set  of  improvement  requirements 
and  opportunities,  and  a  class  of  improvement 
effort.  There  are  four  classes  of  process 
improvements: 

Class  1 :  Quick  fixes  that  require  little  or  no 
organizational  or  technical  changes 

Class  2:  Improvements  that  require 

organizational  changes,  but  have 
little  or  no  impact  on  existing 
information  systems 


Class  3:  Improvements  that  require 

technical  improvements,  but  have 
little  or  no  impact  on  existing 
organizational  structures 

Class  4:  Improvements  that  require 

significant  organizational  and 
technical  enablers  and  have  major 
impacts  on  the  existing  information 
and  technical  infrastructure. 

When  developing  initiatives,  it  is  helpful  to 
consider  five  elements  of  a  process  improvement 
program: 

1 .  Vision  statement,  which  provides  overall 
guidance  for  improvement  efforts 

2.  Process  characteristics; 

A.  Workflow  through  the  process 

B.  Output  requirements  for  products/ 
services  (internal  and  external) 

C.  Stakeholder  requirements 

D.  Organizational  support  factors 

E.  Technology  support  factors 

3.  Performance  measures  and  objectives: 

A.  Fitness  for  purpose 

B.  Conformance  to  standards 

C.  Process  response  and  cycle  time 

D.  Process  variable  and  fixed  costs 

4.  Critical  success  factors: 

A.  Related  to  people 

B.  Related  to  technology 

C.  Related  to  products 

5.  Potential  barriers  to  implementation: 

A.  Resource  availability  and  allocation 

B.  Cultural  and  cross-functional  issues 

C.  Technical 

D.  Product/service  requirements 

E.  Regulatory  constraints  and 
restrictions. 

5.3.4  Redesign/Redevelop  Business  Processes. 
There  are  only  three  actions  the  team  can  do  to 
improve  the  process: 
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■  Design  the  process  to  be  more  effective 

■  Design  the  process  to  be  more  efficient 

■  Design  the  process  to  be  more 
responsive,  flexible,  and  adaptable. 

There  are  only  three  enablers  of  process 
design: 

■  Streamlining 

■  Technology 

■  Empowerment. 

At  this  point  in  the  methodology,  the  process 
improvement  team  has  all  the  information  it  can 
reasonably  expect  to  have  to  employ  enablers  to 
achieve  process  design  objectives.  The  task  at  hand 
is  to  use  this  information  in  creative  and  daring 
ways  to  come  up  with  innovative  process  designs. 
The  design  effort  should  focus  on  measures  because 
it  is  through  measures  that  an  effective  business 


case  can  be  developed  that  will  gain  management 
acceptance. 

Most  of  the  measures  should  be  already 
captured  in  performance  cell  descriptions.  The 
most  important  measurement  categories  are 
repeated  in  Figure  5-5. Some  of  these 
measurement  categories  will  require  creative  efforts 
to  quantify. 

Organizational  enablers  are  needed  to  achieve 
process  flexibility  design  objectives.’’  This  is 
hecaust  flexibility  is  by  definition,  the  ability  to 
respond  to  situations  and  events  that  have  not  been 
planned.  Cross-functional  work  teams  can  help 
overcome  barriers  resulting  from  problems  or 
situations  that  affect  two  or  more  functional  areas. 
The  usual  terms  for  cross-functional  impediments 
are  red  tape  and  bureaucracy.  Worker 
empowerment  is  a  powerful  tool  for  building 


Efficiency  Measures 

Effectiveness  Measures 

Flexibility  Measures 

Process  Cycie  Time 

Product  Appearance 

Degree  that  people  are 
empowered  to  act 

Performance 

Resources  Expended  per 

Unit  of  Output 

Reliability 

Percentage  of  events 
customers  expectations 
are  exceeded 

Timeliness 

Value-added  Cost  per 

Unit  of  Output 

Usability 

Degrees  of  difficulty  to 
respond  to  special 
requests 

Serviceability 

Ratio  of  Value  Added  to 
Non-value  Added  Time 

Durability 

Authority  people  have 
to  continuously  improve  the 
process 

Cost 

Cost  of  Poor  Quality 

Responsiveness 

Amount  of  time  it  takes  to 
adjust  the  process  to 
handle  new  requirements 

Dependability 

Wait  and  Delay  Time  per 

Unit  of  Output 

Accuracy 

Number  of  pre-planned 
process  scenarios 

Adaptability 

Figure  5-5.  Process  Measures 


16  See  Harrington,  chapter  3. 

17  See  Clemmer,  chapter  5. 
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flexibility  into  processes.  When  workers  are 
empowered  to  solve  customer  problems,  processes 
are  by  definition  more  flexible.  Managers  and 
supervisors  enable  process  improvement  when  their 
roles  shift  from  controlling  employees  and 
enforcing  rules  to  coaching  team  members  and 
removing  impediments  to  serving  customers  and 
other  stakeholders. 

Technology  enablers  are  needed  to  achieve 
both  process  effectiveness  and  efficiency.  Some  of 
the  benefits  of  enabling  technology  are  listed  in 
Figure  5-6. 

In  summary,  process  improvement  can  be 
thought  of  as  a  combination  of  the  following.*’ 

■  Redesign  of  appropriate  processes  or 
subprocesses 

■  Redesign  of  business  functions,  job 
tasks,  job  workflows,  and  position 
descriptions 

■  Design  of  computer  and  communication 
systems  enhancements 


■  Redesign  of  departmental  (functional) 
operations  workflow 

■  Creation  or  modification  of  policies, 
directives,  guidance,  rules,  and 
standards. 

The  design  of  the  new  process  is  captured  in 
high-level  TO-BE  activity  and  data  models  along 
with  narratives  of  process  design  features  supported 
with  charts  and  graphs.  TO-BE  models  should  be 
detailed  enough  to  capture  the  design  features  of  the 
new  process,  but  they  should  not  be  fully  developed 
until  after  the  designs  have  been  validated. 

5.3  J  Refine/Redevelop  Process  Deployment 
Map.  Process  redesign  will  affect  the  current 
organizational  structure  as  subprocesses  and 
activities  are  consolidated  or  reassigned  to 
functional  elements.  After  the  TO-BE  models  have 
been  developed,  the  process  improvement  team 
should  redevelop  the  process  deployment  map  or 
matrix  that  illustrates  the  interaction  of  process  to 
function.  New  or  changed  boundary  conditions 
should  also  be  documented  as  the  first  step  in 
designing  new  policies,  procedures,  and  work  rules. 


Automation 

Replacing  human  labor  with  machine  labor 

Information 

Capturing  process  information  to  improve  understanding 

Sequential 

Changing  the  sequence  of  activities  or  enabling  parallelism 

Tracking 

Closely  monitoring  process  status  to  enable  fast  response 

Analyticai 

Improving  analysis  of  information  and  enabling  decision 
making 

Geographical 

Coordinating  processes  across  distances 

Integrative 

Coordination  between  tasks  and  processes 

Intellectual 

Capturing  and  distributing  expert  knowiedge  and  decision  rules 

Disintermediating 

Eliminating  intermediaries  from  a  process 

Figure  5-6.  Technology  Enablers  for  Process  Improvement 


18  See  Davenport,  chapter  3. 

19  See  Morris  and  Brandon,  chapter  7. 
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5.3.6  Describe  and  Quantify  New  Stakeholder 
Relationships.  Working  from  the  new  process 
deployment  map,  the  improvement  team  next 
revisits  stakeholder  relationships  to  the  new  process 
design.  If  the  needs  of  stakeholders  were 
considered  in  the  new  process  design,  the  interests, 
requirements,  and  measures  relating  to  stakeholders 
will  change. 

5.3.7  Revise  Future  State  Performance  CeU 
Descriptions.  Process  redesign  and  reengineering 
changes  need  to  be  reflected  in  the  performance 
cells  for  the  process.  Objectives,  critical  success 
factors,  and  specific  process  measures  may  have 
changed  as  a  result  of  process  design  changes. 
Current  and  accurate  performance  cell 
documentation  will  facilitate  FEA  development, 
enterprise  engineering  activities,  prototyping, 
testing,  and  new  process  deployment. 

5.3.8  Validate  Initiatives  and  Models  Against  All 
Requirements.  At  this  point,  the  process 
improvement  team  should  validate  all  process 
redesign  and  reengineering  changes  vrith  respect  to 
the  following  elements: 

■  Process  vision  statement 

■  Business  plan  objectives  and  goals 

■  Stakeholder  requirements 

■  Performance  cell  requirements. 

This  validation  task  is  the  last  opportunity  the 
improvement  team  will  have  to  make  corrections 
and  adjustments  in  the  process  design  before 
materials  and  documents  are  formally  distributed 
outside  the  improvement  team. 

5.3.9  Select  Alternatives  for  Process 
Improvement  Actions.  Once  the  design  elements 
have  been  validated,  the  process  improvement  team 
next  looks  for  alternatives  in  the  way  process 
improvements  will  be  implemented.  The  team 
should  seek  to  document  from  three  to  five 
alternatives  including  the  status  quo  (no  process 
changes.)  Alternatives  will  generally  apply  to 
organizational  and  technology  enablers,  rather  than 
to  internal  process  changes.  Oiganizational 
alternatives  include  the  formation  of  self-managed 
teams  to  support  a  process  design  versus  standard 


manager-subordinate  structures.  Technical 
alternatives  might  involve  the  use  of  a  distributed 
data  base  versus  a  central  data  base  concept. 
Alternatives  might  also  deal  with  technology  sizing. 
For  instance,  should  personal  computers  with  486 
microprocessors  be  obtained,  or  should  pentium 
chip  computers  be  recommended? 

5.3.10  Perform  Economic  Analysis  on 
Alternatives.  Once  a  set  of  alternatives  has  been 
developed,  the  next  task  is  to  perform  a  preliminary 
economic  analysis  on  the  alternatives.  This  is  the 
only  reliable  way  to  judge  the  merits  of  alternatives. 
An  economic  analysis  follows  a  straightforward  six- 
step  methodology  described  in  Section  10  of  this 
guide.  The  analysis  will  center  on  the  assumptions 
and  constraints  associated  with  developing 
alternatives,  costs  and  benefits  of  each  alternative, 
and  the  risks  associated  with  each  alternative.  This 
data  will  be  passed  forward  to  the  next  step  in  the 
methodology,  which  is  FEA  development. 

5.3.11  Develop  DetaUed  TO-BE  Activity  and 
Data  Models.  Once  the  improvement  team  has 
considered  all  reasonable  alternatives,  the  next  task 
is  to  complete  development  of  the  TO-BE  activity 
and  data  models  for  the  most  promising  alternative 
to  the  level  necessary  to  capture  all  design  features. 
Supporting  design  documentation  should  also  be 
completed  at  this  time.  The  resulting  models  should 
be  suitable  for  distribution  to  the  technical  elements 
once  the  FEA  decision  package  has  been  approved. 
If  necessary,  other  alternatives  can  be  modeled  and 
documented  later. 

Once  TO-BE  models  are  complete,  simulation 
techniques  should  be  applied  to  test  the  expected 
results.  Please  see  the  Function  Simulation 
Guidebook  for  information  on  simulation.  Finally, 
a  functional  integration  analysis  should  be 
completed  to  ensure  that  all  cross-functional 
considerations  have  been  addressed. 

5.3.12  Initiate/Coordinate  Data  Administration 
Activities.  The  TO-BE  data  models  are  now 
suitable  for  distribution  to  data  administration 
persoimel  so  that  work  can  begin  on  rationalizing 
the  data  models  that  support  the  new  process  with 
the  enterprise  data  model.  Data  administration  will 
complete  this  task  by  developing  the  Data 
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Management  Plan  (DMP),  which  will  be  included  in 
the  FEA  in  the  following  step. 

5.3.13  Initiate/Coordinate  Information  Systems 
Activities.  The  TO-BE  activity  models  are  now 
suitable  for  distribution  to  information  systems 
technical  staff  so  that  work  can  begin  on 
rationalizing  the  required  application  systems 
changes  and  enhancements  with  the  current  systems 
migration  plan.  Technical  elements  will  complete 
this  task  by  developing  the  Technical  Management 
Plan  (TMP),  which  will  be  included  in  the  FEA  in 
the  following  step. 

5.3.14  Prepare  Final  Process  Design 
Specifications.  The  process  improvement  team 
now  prepares  the  find  process  design  specification 
package  reflecting  all  recommended  process 
changes  and  enhancements  including  organizational 
and  technical  features.  This  package  will  consist  of 
TO-BE  models  with  sufficient  supporting 
documentation  to  facilitate  development  of  the  FEA 
formal  business  case  and  management  decision 
package. 

5.3.15  Review  and  Approve  Process  Design 
Specifications.  The  process  design  specification 
package  is  submitted  to  higher  authority  for  review 
and  approval.  Higher  authority,  in  this  case,  is 
usually  composed  of  the  process  owner,  and 
improvement  sponsors.  Principal  Staff  Assistants, 
and  Functional  Information  Managers.  Following 
review  and  approval,  the  final  business 
reengineering  document,  the  FEA,  is  prepared 
during  the  next  step  in  the  methodology. 

5.4  Step  9:  Prepare  Functional  Economic 

Analysis  Decision  Package 

At  this  point  in  the  business  process 
reengineering  phase,  the  improvement  team  has 
developed  a  program  of  process  improvements  that 
takes  into  account  business  objectives  from  the 
planning  phase  and  opportunities  for  improvement 
based  on  an  analysis  of  the  process  itself.  The 
improvement  team  has  also  evaluated  organizational 
and  technical  enablers  and  constraints  as  they  affect 
the  proposed  process  improvements.  This  step  is 


concerned  with  developing  a  formal  business  case, 
or  case  for  action  as  it  is  sometimes  called. 

To  this  point  in  the  methodology,  the  only 
funds  expended  have  been  those  needed  to  support 
the  process  improvement  team  in  developing  a 
proposed  course  of  action  for  process  improvement. 
There  has  been  little  or  no  disruption  to  current 
process  operations.  To  go  forward  from  this  point 
into  enterprise  engineering  and  especially  project 
execution,  major  funding  will  be  needed  to  support 
the  proposed  improvements.  In  addition,  functional 
organizations  may  be  required  to  make  highly 
disruptive  changes  in  the  way  workflow  is 
managed.  In  other  words,  the  element  of  risk  with 
respect  to  costs  and  benefits  must  be  considered 
before  approval  to  proceed  can  be  granted. 

The  Functional  Economic  Analysis  (FEA)  is  a 
management  decision  support  package  designed  to 
provide  higher  authority  with  all  of  the  information 
needed  to  make  an  informed  decision  on  whether  to 
proceed  with  the  proposed  slate  of  changes  and 
improvements.  Figure  5-7  illustrates  the  position  of 
the  FEA  with  respect  to  the  total  process 
improvement  methodology.  As  Figure  5-7 
indicates,  the  FEA  should  be  a  summary  of  all  the 
critical  decision  support  data  provided  by  all 
process  improvement  activities  to  this  point. 
[Organizational  (phase  2B)  and  Technical  (phase 
2C)  Change  Management  are  presented  in  Sections 
6  and  7  in  this  guide.]  To  summarize,  the  FEA  is  a 
major  control  point  in  the  process  improvement 
methodology  and  cannot  be  completed  until  phases 
2B  and  2C  are  performed. 

The  FEA  package  is  divided  into  eight 
sections.  Although  it  is  a  functional  management 
responsibility,  it  requires  support  from  technical 
elements  to  produce.  It  includes  the  final  economic 
analysis  for  the  proposed  process  improvement 
alternative,  a  summary  of  other  alternatives  that 
were  considered,  a  synopses  of  strategic  and 
business  planning  objectives,  and  a  summary  of  the 
supporting  data  and  information  technical  plans. 

The  Functional  Economic  Analysis  Guidebook 
should  be  read  for  specific  guidance  on  preparing 
the  FEA. 
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Project  Execution 


Figure  5-7.  Functional  Economic  Analysis 


The  features  of  an  acceptable  FEA  include  the 
following: 

■  It  is  comprehensive,  presenting  sufficient 
financial  and  non-financial  data  to 
support  an  informed  management 
decision. 

■  It  provides  sufficient  justification  to 
warrant  an  investment  in  process, 
organizational,  and  technical  changes 
and  improvements. 

■  It  clearly  communicates  the  current 
situation  with  respect  to  the  process 
under  improvement  and  alternatives 
means  of  making  process  improvements. 

■  It  has  internal  consistency  with  respect  to 
data  presentation,  analysis,  and 
documentation  (supports  an  apples-to- 
apples  type  of  comparison). 

■  It  includes  a  risk  assessment. 


■  It  includes  performance  measures  that 
can  be  used  to  monitor  project 
continuation  upon  FEA  approval. 

The  following  tasks  are  performed  in  the  FEA 

■  Review  process  improvement 
recommendations 

■  Review  organizational  change 
management  plan  (from  Section  6.3.5) 

■  Review  technology  change  management 
plan  (from  Section  7.3.6) 

■  Develop  preliminary  Functional 
Economic  Analysis  (FEA) 

■  Develop  preliminary  data  and  technical 
management  plan 

■  Perform  technical  review  of  FEA 
documents 
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■  Validate/revise  preliminary  FEA  report 

■  Prepare  final  Functional  Economic 
Analysis  report 

■  Review  and  approve  FEA 

5.4.1  Review  Process  Improvement 
Recommendations.  The  first  step  in  FEA 
preparation  is  to  review  the  process  improvement 
report  produced  in  the  preceding  step.  This  review 
should  isolate  those  parts  of  the  report  that  need  to 
be  included  in  the  FEA.  The  FEA  is  a  summary 
document  and  should  only  include  critical 
management  decision-support  data.  Where 
required,  the  FEA  can  refer  to  supporting 
documents  including  the  process  improvement 
report. 

This  review  should  also  note  information  that 
is  lacking  or  needs  further  development  for 
inclusion  in  the  FEA.  The  improvement  team 
should  refer  to  the  FEA  Guidebook  and  examples  of 
acceptable  FEAs  to  aid  in  this  assessment. 

5.4.2  Review  Organizational  Change 
Management  Plan  (6.3.5).  Process  improvement 
is  invariably  associated  with  organizational  change 
management.  During  the  performance  of  the  first 
three  steps  in  this  phase,  organizational  enablers  and 
constraints  were  considered  by  the  person  or  team 
responsible  for  considering  organizational  issues. 
Before  the  FEA  can  be  produced,  the  results  of 
phase  2B  (Organizational  Change  Management) 
must  be  considered.  The  required  organizational 
changes  are  included  in  the  FEA  so  that  higher 
authority  can  judge  the  merits  of  the  recommended 
process  improvements  with  respect  to  the 
organizational  impacts  of  the  new  process.  Task 
6.3.5  prepares  the  required  report. 

5.4.3  Review  Technology  Change  Management 
Plan  (7.3.6).  Process  improvement,  especially 
process  reengineering,  will  almost  always  require 
the  application  of  new  information  technologies  as 
well  as  changes  and  enhancements  to  the  existing 
information  systems  infrastructure.  Technology 
enablers  and  constraints  will  have  been  considered 
by  the  person  or  team  assigned  to  perform  Phase 
2C-Technology  Change  Management.  The  results 


of  this  team’s  work  must  be  considered  before  the 
FEA  can  be  completed.  It  is  important  to 
distinguish  between  the  costs  and  risks  of  new 
technology  enablers  and  the  costs  and  risks  of 
making  changes  to  existing  information  systems 
structures,  which  often  act  as  constraints  to  process 
improvement.  Task  7.3.6  produces  the  required 
report. 

5.4.4  Develop  Preliminary  Functional  Economic 
Analysis  (FEA).  Once  the  three  inputs  described 
above  have  been  considered,  the  process 
improvement  team  can  develop  a  preliminary  FEA. 
The  FEA  is  preliminary  in  the  sense  that  it  does  not 
include  a  thorough  analysis  of  the  data  management 
and  technical  management  issues  associated  with 
the  DoD  Enterprise  Model  or  the  existing 
information  inf^rastructure,  including  legacy  and 
migration  systems  issues.  However,  the  technical 
elements  cannot  reliably  provide  the  this 
information  until  they  have  a  good  understanding  of 
the  proposed  process  improvement  project  with  the 
associated  organizational  and  technical 
implications.  The  preliminary  FEA  along  with 
supporting  information  including  activity  and  data 
models  delivers  this  information.  The  following 
sections  of  the  FEA  are  written  in  this  task: 

5.4.4.1  Section  1:  Strategic  plan  summary.  This 
section  should  focus  on  the  strategic  planning 
objectives  with  respect  to  the  process  under 
consideration.  This  section  should  include  a 
discussion  of  breakthrough  objectives,  critical 
success  factors,  cross-functional  considerations,  and 
responsibility  assignments.  Mission  and  vision 
considerations  should  be  used  as  the  justification  for 
the  improvement  project  effort.  Also  included  in 
this  section  are  any  impacts  due  to  Defense 
Management  Review  decisions  and  fiscal 
adjustments. 

5.4.4.2  Section  2:  Business  plan  summary.  This 
section  should  focus  on  annual  business  objectives 
with  respect  to  the  proposed  improvement  project, 
taking  into  consideration  all  cross-functional 
impacts.  A  high-level  process  deployment  map 
should  be  included  along  with  IDEF  context 
diagrams  and  high-level  AS-IS  models  to  illustrate 
critical  data  with  respect  to  improvement  efforts. 
This  section  should  dso  include  a  summary  of 
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objective  decomposition  from  the  process 
improvement  component  of  the  business  plan. 

5.4.4.3  Section  3:  Performance  ceU  summary. 

This  section  should  include  performance  measures, 
targets,  and  stakeholder  benefits  as  extracted  from 
the  performance  cells  developed  during  the 
planning  phase  and  revised  during  the  process 
analysis  and  design  steps  of  this  phase.  Every 
process  improvement  objective  must  be  associated 
with  a  measure  and  a  target.  These  measures  and 
targets  should  be  related  to  process-critical  success 
factors  established  during  the  planning  phase. 

For  the  most  critical  performance  targets,  this 
section  should  provide  a  brief  explanation  of  how 
the  targets  were  selected.  The  usual  sources  are  the 
strategic  plan  and  strategic  benchmarking.  Targets 
may  also  have  been  identified  during  process 
analysis. 

Key  stakeholder  benefits  should  be  well- 
documented  in  this  section  with  respect  to 
performance  measures  and  targets.  This  is 
especially  true  if  significant  compromises  were 
made  in  new  process  design  to  accommodate 
conflicting  interests. 

5.4.4.4  Section  4:  Improvement  program 
description.  This  section  is  where  the  process 
improvement  team  describes  the  overall  process 
improvement  program  in  terms  that  will  support  an 
informed  management  decision  about  the  merits  of 
the  improvement  effort.  All  three  elements  of  the 
process  improvement  program  should  be  described: 
process  enhancements,  organizational  changes,  and 
technical  enablers.  Qualitative  factors  can  be 
described,  provided  they  are  not  expected  to  carry 
the  weight  of  the  decision.  This  section  can  also  be 
used  to  explain  why  the  proposed  alternative  is 
recommended  and  why  the  alternatives  were  not. 
High-level  TO-BE  context  diagrams  and  models 
may  be  included  to  illustrate  proposed 
improvements. 

5.4.4.5  Sections:  Economic  Analysis  of 
Proposed  Process.  The  preliminary  economic 
analysis  performed  earlier  is  refined  based  on  the 


results  provided  by  the  change  management  teams 
and  further  analysis. 

A  standard  economic  analysis  contains  six 

steps: 

■  Clear  statement  of  the  improvement 
opportunity 

■  Assumptions  and  constraints  that  govern 
alternative  development 

■  Description  of  each  viable  alternative 

■  Costs  and  benefits  of  each  alternative 

■  Alternative  analysis  [Risk- Adjusted 
Discounted  Cash  Flow  (RADCF) 
method] 

■  Sensitivity  analysis  to  correct  for 
imprecise  data. 

The  economic  analysis  includes  a  quantitative 
ranking  of  alternatives,  which  should  be 
supplemented  with  a  narrative  describing  critical 
non-quantifiable  or  qualitative  factors  that  influence 
the  selection  of  alternative. 

5.4.5  Develop  Preliminary  Data  and  Technical 
Management  Plan.  The  preliminary  FEA  and 
supporting  data  and  reports  are  used  in  a  series  of 
meetings  and  investigations  with  technical  support 
elements.  Technical  support  elements  working  with 
functional  elements  develop  a  data  management  and 
information  systems  strategy  (Section  6  of  the  FEA) 
that  will  support  the  improvement  project  within  the 
context  of  data  and  systems  infrastmcture 
considerations.  Of  special  importance  in  this 
analysis  are  the  constraints  imposed  by  legacy  and 
migration  systems.  Technical  risks  are  also 
considered  with  respect  to  cross-functional 
integration  issues. 

5.4.6  Perform  Technical  Review  of  FEA 
Documents.  At  this  point,  all  of  the  data  and 
information  relating  to  the  process  improvement 
project  and  all  functional  and  technical  issues  and 
considerations  are  reviewed  for  consistency  by  joint 
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functional  and  technical  elements.  At  this  time, 
potential  problems,  issues,  and  concerns  are 
resolved  or  documented  for  resolution  during  the 
enterprise  engineering  phase  of  the  methodology. 
Also  at  this  time,  additional  data  needed  to  support 
the  development  of  the  final  FEA  are  identified  and 
assigned  as  action  items  for  the  process 
improvement  team. 

5.4.7  Validate/Revise  Preliminary  FEA  Report. 

Once  all  actions  items  assigned  in  the  previous  task 
are  completed,  the  process  improvement  team 
performs  a  final  validation  of  all  data  currently 
assembled  for  the  FEA.  Working  with  the  project 
manager,  the  technical  elements  now  develop 
Section  7-Data  and  Systems  Changes,  and  Section  8 
-Data  and  Systems  Cost  Analysis,  of  the  FEA. 

These  sections  of  the  FEA  briefly  describe  the 
changes  to  data  and  information  systems  support 
that  will  have  to  be  made  with  an  estimate  of  the 
associated  costs. 

The  proposed  systems  changes  and  associated 
costs  will  be  reviewed  and  revalidated  during  the 
enterprise  engineering  phase  of  the  project  when  all 
elements  of  the  improvement  project  are  considered 
in  the  light  of  the  DoD  Enterprise  Model,  the 
current  information  systems  infrastructure,  the 
considerations  associated  with  new  technologies, 
and  the  organizational  change  management  strategy 


and  plan.  At  the  completion  of  the  enterprise 
engineering  phase,  the  FEA  will  be  updated  and 
submitted  for  approval  before  the  project  execution 
phase  begins. 

5.4.8  Prepare  Final  Functional  Economic 
Analysis  Report.  The  process  improvement  team 
now  completes  the  FEA,  and  performs  an  internal 
review  and  validation  effort.  The  process 
improvement  team  should  assure  themselves  that 
the  final  FEA  report  fairly  represents  the  proposed 
project  and  provides  sufficient  data  for  higher 
authority  to  make  an  informed  decision.  The 
Functional  Economic  Analysis  Guidebook  should 
be  referenced  to  ensure  that  all  elements  of  the  FEA 
are  complete  and  in  the  required  format.  The 
improvement  team  will  also  prepare  a  short  briefing 
package  with  visuals  that  can  be  used  to  brief 
management  and  review  teams  as  necessary. 

5.4.9  Review  and  Approve  FEA.  The  FEA 
decision  package  is  presented  to  higher  authority  for 
review  and  approval.  Following  review  and 
approval,  the  improvement  team  advances  to  the 
next  phase  of  the  methodology,  enterprise 
engineering. 
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CHANGE  MANAGEMENT 


SECTION  6.  PHASE  2B:  ORGANIZATIONAL 

Business  process  improvement  inevitable 
requires  change  to  an  organization’s  structure  and 
culture.  All  change  is  disruptive.  Therefore, 
business  process  improvement  is  disruptive  to  an 
organization’s  structure  and  culture.  Enterprises 
that  have  attempted  process  improvement  while 
ignoring  this  syllogism  have  invariably  failed.  This 
means  that  organizational  change  management  is 
the  most  critical  responsibility  in  an  overall 
program  of  process  improvement. 

Organizational  change  management  begins 
during  the  planning  phase  and  extends  through  the 
project  execution  phase.  Thus,  dealing  with 
organizational  change  is  a  continuous  responsibility. 
This  responsibility  may  be  vested  in  one  member  of 
the  improvement  team,  or  it  may  be  the 
responsibility  of  a  separate  team  chartered  to 
support  all  process  improvement  teams.  The  former 
works  when  only  one  process  improvement  effort  is 
under  way  across  a  group  of  functional  units;  the 
latter  is  necessary  when  functional  units  are  affected 
by  two  or  more  improvement  efforts. 

Figure  6-1  shows  how  a  change  management 
team  can  serve  as  the  focus  or  hub  for  multiple 
process  improvement  efforts.  This  arrangement 
allows  the  change  management  team  to  take  a 
broader  view  of  the  relationship  of  process  to 
organization  to  help  ensure  that  organizational 
change  management  efforts  are  coordinated  for  all 
improvement  efforts.  Technology  change 
management,  discussed  in  Section  7  of  this  guide,  is 
also  best  dealt  with  by  an  independent  change 
management  team  working  with  separate  process 
improvement  teams. 

Figure  6-1  also  shows  that  change 
management  must  consider  the  external 
environment,  external  stakeholders,  and  the 
technical  infrastructure  when  attempting  to  shape 
the  organization’s  structure  and  culture  around 
improved  processes. 


The  role  of  the  organizational  change 
management  team  or  person  is  to  ensure  that  the 
organization’s  structure  and  culture  will  be  able  to 
successfully  assimilate  the  improved  process.  An 
established  change  management  team  may  even  be 
able  to  develop  enablers  that  help  guide  design  of 
the  new  process. 

Structural  change  management  is  concerned 
with  the  way  a  functional  unit  is  organized  to  carry 
out  its  work  responsibilities.  This  includes  policy 
and  procedure,  rules  and  regulations,  management 
and  staffing,  facilities  and  equipment,  and  human 
resource  practices.  Structural  change  management 
has  to  do  with  things  or  facilities. 

Cultural  change  management  is  concerned 
with  the  way  people  interact  with  each  other  both  in 
peer  relationships  and  superior/subordinate 
relationships.  Cultural  change  management  has  to 
do  with  people,  and  is  therefore  the  more  difficult  of 
the  two  to  successfully  deal  with. 

People  and  culture — the  human  systems  of  an 
enterprise — are  what  make  or  break  any  change 
initiative. 

The  change  management  team  must 
accomplish  four  general  objectives: 

■  Understand  the  organizational  changes 
that  are  needed  as  a  consequence  of 
process  redesign  or  reengineering 

■  Design  the  necessary  structural  changes 
needed  to  support  the  new  process 

■  Design  a  program  that  will  begin  the 
cultural  transformation  of  the 
organization  to  one  that  is  aligned  with 
the  principles  behind  process 
improvement 

■  Anticipate,  recognize,  and  resolve  the 
barriers  to  change  that  will  spring  up  in 
reaction  to  the  change  management  plan. 
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Figure  6'1.  Change  Management  Schematic 


Solid  change  demands  careful  planning  with 
inputs  from  all  levels  of  the  organization.  Carefully 
timed  action  steps  support  change  implementation. 
This  requires  answers  to  the  who,  what,  when, 
where,  and  why.“ 

■  Is  the  organization’s  leadership  prepared 
to  lead  the  change  effort? 

■  Have  we  primed  the  organization  for 
planned  changes? 


■  Is  the  organizational  structure  ready  to 
support  change? 

■  Do  team  members  have  the  right  mix  of 
skills  to  make  the  changes  happen? 

■  Is  success  a  reasonable  expectation? 

■  Are  functional  managers  properly 
committed  to  the  planned  change? 


20'  Management  Processes  for  Quality  Operations,  Richard  S.  Johnson,  ASQC  Quality  Press,  1993. 
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■  Are  sufficient  resources  available  to 
support  the  change  effort? 

Negative  answers  to  the  above  questions 
suggest  areas  for  the  improvement  team  to  work  on 
because  experience  has  shown  that  unless  and  until 
all  questions  can  be  answered  in  the  affirmative, 
successful  implementation  of  redesigned  processes 
is  at  considerable  risk. 

Barriers  to  change  management  success  are 
well  known.  They  generally  include  the  following 
and  all  must  be  successfully  contained  or  resolved 
or  the  success  of  the  process  improvement  cannot 
be  reasonably  assured: 

■  Lack  of  active,  visible,  and  committed 
leadership 

■  Ignorance  of  improvement  goals  and 
employees’  roles  in  achieving  them 

■  Ingrained  satisfaction  with  the  status  quo 

■  Vested  interests  in  keeping  things  as  they 
are 

■  Inadequate  training  and  preparation  for 
the  change  effort 

■  Hostility  directed  at  members  of  the 
improvement  or  change  teams 

■  No  or  little  reward  or  recognition  for 
participating  in  the  change  effort 

■  Threats  to  personal  security  and  career 
objectives 

■  Lack  of  organizational  support 

■  Inadequate,  infrequent,  or  deceiving 
communications  about  the  changes. 

There  have  been  enough  successes  with 
process  improvement  that  some  general  principles 
to  guide  organizational  change  can  be  expressed. 
These  principles  can  be  used  by  change 
management  teams  to  design  a  program  to  support 
process  improvement  with  assurance  that  the 
principles  have  worked  for  other  organizations.  It 
must  be  remembered,  though,  that  change  involving 
people,  their  perceptions,  and  attitudes  takes  time  to 
settle  in.  Therefore,  these  principles  function  more 
as  a  direction  for  change  than  an  immediate 
destination.  This  in  no  way  invalidates  their  use. 


■  Process  management  must  be  instituted 
in  such  a  way  that  functional  managers 
can  support  it  (see  Figure  6-2,  value- 
chain  versus  control-chain). 

■  Management  hierarchies  must  be 
flattened  to  make  the  organization  more 
flexible  and  responsive  to  changing 
conditions. 


■  Employees  must  be  involved  in  decision 
making  and  empowered  to  act  on  behalf 
of  internal  and  external  customers. 

■  Work  must  be  reorganized  around  cross¬ 
functional  work  groups  (teams)  who 
have  responsibility  for  cost,  quality,  and 
cycle  time  performance. 

■  Unnecessary  and  obsolete  mles  and 
regulations  that  inhibit  process 
performance  must  be  reduced  or 
eliminated. 

■  Continuous  and  just-in-time  learning 
practices  must  be  put  in  place  to  facilitate 
skill  development,  cross-functional 
cooperation,  and  work  group  flexibility. 

■  Managers  must  manage  less  and  lead 
more. 

■  The  new  values  of  commitment, 
teamwork,  performance,  and 
accomplishment  must  displace  the  old 
values  of  risk  avoidance,  strict 
accountability,  self-aggrandizement,  and 
functional  myopia. 

■  Rewards  and  recognition  must  be  aligned 
with  team  accomplishment  of  process 
performance  goals  and  individual  skill 
and  competency  development. 

Figure  6-2  illustrates  the  relationship  between 
process  management  and  functional  management. 
While  there  are  academic  arguments  concerning 
whether  enterprises  should  keep  a  primarily 
functional  organizational  structure  or  adopt  process 
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Functional  Management  must 
co-exist  in  the  modern 
enterprise. 

Functional  Management  sets 
controls  on  processes,  provides 
resources,  and  maintains  a 
body  of  functional  skills  and 
professional  expertise. 
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Process  Management  provides 
continuity  within  the  planning  / 
performance  cycle. 

Feedback  measures  are  used  to 
improve  processes  and  reformulate 
stratetgic  and  business  plans. 

Process  Improvement  ensures  an 
optimum  balance  within  the  value- 
chain  (process)  and  the  control-chain 
(function). 


Figure  6-2.  Process/Function  Management  Model 


management  as  an  organizational  concept,  it  would 
seem  that  there  is  a  need  for  both  in  large,  complex 
enterprises.  Process  management  provides  the 
useful  construct  of  the  value-chain,  while  functional 
management  provides  an  equally  useful  construct  of 
the  control-chain.  Change  management  teams 
should  strive  to  maximize  the  potential  of  each  with 
respect  to  process  improvement  efforts. 


At  the  completion  of  this  phase,  the  change 
management  team  will  have  produced  a  change 
management  plan  aligned  with  process 
improvement  objectives.  The  change  management 
plan  will  be  included  in  the  Functional  Economic 
Analysis  decision  support  package.  As  the 
improvement  project  moves  through  the  enterprise 
engineering  and  project  execution  phases,  the 
change  management  team  will  coordinate  change 
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management  actions  with  process  improvement 
actions. 

The  change  management  phase  of  the 
Framework  for  Managing  Process  Improvement  is 
supported,  in  part,  by  the  following  resources: 

■  F/MPI  Management  Briefing  on 
Organizational  Change  Management 

■  F/MPI  Organizational  Change 
Management  Tutorial 

■  Merced  County  Case  study  in  Change 
Management. 

The  techniques  (described  in  Section  10)  most 
useful  in  this  phase  include  the  following: 

■  Brainstorming 

■  SWOT  Analysis 

■  Affinity  Diagram 

■  Cause  and  Effect  Diagram 

■  Force  Field  Analysis 
,  ■  Pareto  Analysis 

6.1  Step  10:  Assess  Organizational  CapabUity 

Before  process  improvement,  there  is  the 
organization.  This  step  assesses  current 
organizational  capability  with  respect  to  process 
improvement  efforts.  In  this  sense,  this  step  serves 
as  a  baseline  from  which  to  plan,  design,  and 
develop  organizational  improvements  that  will  be 
required  for,  or  that  will  support,  process 
improvement  efforts. 

Once  the  change  management  team 
understands  the  strengths  and  weaknesses  of  the 
organizational  units  affected  by  potential  process 
improvement  efforts,  they  can  better  plan  a  series  of 
changes  and  improvements  that  will  condition 
organizations  to  accept  the  new  process.  The 
change  management  team  should  be  cognizant  of 
the  fact  that,  where  possible,  it  may  be  better  to 
shape  the  new  process  around  organizational 
strengths  rather  than  attempt  to  correct  all 
organizational  weaknesses  in  one  go-around. 


When  the  tasks  in  this  step  are  complete,  the 
change  management  team  will  be  positioned  to 
identify  and  prioritize  a  series  of  organizational 
changes  needed  to  support  planned  process 
improvements. 

The  following  tasks  are  performed  in  the 
assess  organizational  capability  step: 

■  Review  process  improvement 
organizational  implications 

■  Assess  organizational  status  (strengths 
and  weaknesses) 

■  Document  current  organizational  status 

■  Review  and  approve  organizational 
situation  report. 

6.1.1  Review  Process  Improvement 
Organizational  Implications.  The  first  task  in 
change  management  is  actually  a  continuing  task. 
As  the  process  under  study  moves  through  the 
reengineering  phase,  the  change  management  team 
constantly  looks  for  the  organizational  implications 
of  suggested  or  proposed  process  changes  and 
improvements.  This  is  one  reason  that  change 
management  should  be  dealt  with  outside  of  the 
process  improvement  team.  It  is  quite  easy  for  the 
improvement  team  members  to  devalue  the  impact 
of  potential  changes  on  organizational  units  without 
this  dispassionate  perspective. 

The  implications  the  change  management 
team  should  evaluate  include  the  following: 

■  Organizational  structure  changes,  which 
can  include  hierarchical,  flat,  functional 
teams,  cross-functional  teams, 
centralized,  decentralized,  and  matrix 
structures 

■  Process  vision  with  respect  to  enterprise 
vision 

■  General  climate  of  the  affected 
functional  units  with  respect  to  tolerance 
for  change  and  growth 

■  Morale  as  it  might  support  or  hinder 
improvement  efforts 
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■  Physical  environment  with  respect  to 
process  (workflow)  changes 

■  Training  and  development  impacts  due  to 
changed  processes  and  structural 
adjustments 

■  Employee  involvement  in  new  process 
operation  as  well  as  in  the 
implementation  and  deployment  phase  of 
the  improvement  project 

■  Recruiting  practices  with  respect  to  type 
of  individuals  sought  to  staff  the  new 
process  for  example,  the  need  for  team 
players  rather  than  rugged  individualists 

■  Alternate  staffing  issues  related  to  part- 
time,  contract  employees,  and  out¬ 
sourcing 

■  Compensation  or  grade-level 
implications 

■  Reward  and  recognition  adjustments 

■  Performance  appraisal  and  career  path 
implications. 

Because  changes  involving  people  usually 
take  considerable  time  to  evaluate,  approve,  and 
enact,  the  change  management  team  must  begin 
their  consideration  of  potential  process 
improvement  impacts  on  structure  and  culture 
during  the  planning  phase  of  the  improvement 
project. 

6.1,2  Assess  Organizational  Status  (Strengths/ 
Weaknesses).  Once  the  change  management  team 
begins  to  understand  potential  impacts  on  structure 
and  culture,  it  needs  to  evaluate  the  current  situation 
in  all  potentially  affected  functional  units.  This  is 
much  like  establishing  the  process  baseline. 
Unfortunately,  the  culture  of  an  organization  cannot 
be  neatly  modeled  with  boxes  and  arrows. 

The  Department  of  Defense  has  produced  the 
“Quality  and  Productivity  Self-Assessment  Guide” 
which  enables  an  improvement  or  change 
management  team  to  measure  four  aspects  of  an 


organization  related  to  process  improvement.  The 
four  elements  are: 

■  Climate — people’s  perceptions  of  the 
organization  and  work  groups 

■  Processes  the  organization’s  policies, 
practices,  and  procedures 

■  Management  tools — the  specific 
techniques  used  to  promote  quality 
management  improvements  throughout 
the  organization 

■  Outcomes — ^factors  related  to  mission, 
objectives,  and  goals. 

The  assessment  instrument  is  reproduced  in 
Appendix  G  and  may  be  copied  and  distributed  as 
needed.  There  are  215  questions,  which  will  take 
about  15  minutes  to  answer.  It  is  important  to 
remember  that  the  term  customer  may  refer  to  an 
internal  or  external  person  or  agency  that  receives 
work  from  a  process  or  work  activity.  After  scoring 
the  assessment,  the  change  team  will  have  a  better 
understanding  of  the  organization’s  readiness  for 
change  and  process  improvement. 

An  IBM  PC-compatible  software  version  of 
this  assessment  can  be  obtained  from  DPPO,  Two 
Skyline  Place,  Room  1404, 5203  Leesburg  Pike, 
Falls  Church,  Virginia  22041,  (703)  756-2346. 

6.13  Document  Current  Organizational  Status. 
With  a  baseline  assessment  of  organizational 
readiness  for  change,  and  an  understanding  of  the 
potential  impacts  of  process  improvement  on 
affective  functional  units,  the  change  management 
team  can  develop  a  status  or  situation  report.  This 
report  will  note  the  areas  and  issues  of  most  concern 
with  respect  to  organizational  change  and  process 
improvement.  Areas  of  both  strength  and  weakness 
should  be  highlighted. 

This  report  will  be  used  later  in  this  phase  to 
develop  an  action-oriented  plan  to  enhance 
organizational  enablers,  remove  obstacles,  and 
lower  barriers  to  change  and  improvement.  The 
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report  may  also  be  used  by  the  process 
improvement  team  itself  to  adjust  process  design, 
wherever  possible,  to  take  advantage  of  strengths 
and  avoid  or  minimize  the  impact  of  weaknesses  in 
organizational  factors. 

6.1.4  Review  and  Approve  Organizational 
Situation  Report.  The  situation  report  should  be 
reviewed  and  approved  (validated)  by  the  process 
improvement  team  and  functional  managers  who 
are  sponsors  of,  and  targets  of,  the  improvement 
effort.  In  as  much  as  sensitive  issues  are  addressed 
in  the  situational  report  and  much  of  the  evaluation 
is  based  on  subjective  factors  subject  to 
interpretation,  the  detailed  situation  report  should 
not  be  widely  distributed.  A  summary  of  general 
conclusions  and  recommendation  may  be  prepared 
and  distributed. 

6.2  Step  11:  Identify  Organizational  Change 

Requirements 

The  previous  step  in  this  phase  produced  in  an 
assessment  of  the  current  situation  of  organizational 
structure  and  culture,  and  an  understanding  of  the 
implications  of  process  improvement  on  functional 
units. 

This  step  will  result  in  an  organizational 
impact  statement  that  defines  the  specific  areas  in 
structure  and  culture  that  have  to  be  addressed  to 
support  the  potential  requirements  of  the 
reengineered  process.  These  requirements  will  be 
defined  in  the  Process  Improvement  Analysis 
Report  produced  in  Step  7,  Conduct  Improvement 
Analysis.  The  organizational  impact  statement 
produced  in  this  step  will  also  include  an  analyzed 
list  of  organization^  enablers  for  use  by  the  process 
improvement  team  in  Step  8,  Redesign/Reengineer 
Process.  The  final  change  management  plan  will  be 
produced  in  the  next  step  in  this  phase. 

W.  Edwards  Deming,^*  who  devoted  his  life  to 
studying  how  to  transform  organizations  into  high- 
quality,  high-performance  enterprises,  developed  14 


points  for  organizational  renewal.  A  study  of  these 
14  points  will  prove  useful  to  change  management 
teams  who  take  time  to  understand  them  and  apply 
them  to  transforming  their  own  organizations. 

“What  management  can  accomplish  using  the 
fourteen  points  is  so  enormous  compared  to  what 
you  get  otherwise,”  Deming  said.  The  following 
points  are  slightly  edited  to  emphasize  their 
applicability  to  process  reengineering. 

1 .  Create  constancy  of  purpose  toward  the 
improvement  of  product,  service,  and 
process  based  on  a  long-term 
commitment  to  continuous  improvement. 

2.  Senior  leaders  must  be  committed  to 
process  improvement  and  take  an  active 
and  visible  role  in  ensuring  that  it  takes 
place. 

3.  The  focus  on  process  improvement  must 
be  to  deliver  high  quality  and  service  to 
the  customer. 

4.  Create  long-term  relationships  and 
partnerships  with  external  and  internal 
suppliers  to  strengthen  the  value-chain 
extending  through  the  process  to  the  final 
customer. 

5.  Decrease  process  costs  with  a  never- 
ending  focus  on  improving  quality  and 
reducing  cycle  time. 

6.  Employ  just-in-time  training  for 
everyone  affected  by  change  and 
improvement. 

7.  Institute  leadership  at  all  levels  in  the 
organization.  A  leader  is  one  who  leads 
from  where  he  or  she  is,  not  from  a 
position  on  an  organization  chart.  That 
is:  a  leader  is  one  who  leads,  it  is  not  a 
title. 


21  The  Deming  Management  Method,  Mary  Walton,  Perigee  Books,  1986. 
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8.  Drive  out  fear  so  that  everyone  may 
work  effectively.  Don’t  use 
reengineering  as  a  cover  story  for 
reductions  in  force  that  would  take  place 
with  or  without  reengineering. 

9.  Break  down  the  barriers  between 
departments  by  instituting  process 
management  principles  and  cross- 
functional  cooperation. 

10.  Eliminate  slogans,  exhortations,  and 
campaigns  that  offend  already  dedicated 
and  willing  employees.  Rather, 
managers  and  supervisors  must  lead  by 
example  and  walk  the  talk. 

1 1 .  Eliminate  work  quotas  bysubstituting 
leadership  and  empowerment  that  focus 
on  delivered  results  rather  than  work 
targets. 

12.  Remove  barriers  that  rob  managers, 
engineers,  and  other  workers  of  their 
right  to  pride  of  workmanship. 

1 3.  Institute  a  vigorous  program  of  education 
and  self-improvement.  Retrain  workers 
for  service  in  the  improved  processes. 

14.  Put  everyone  in  the  organization  to  work 
to  accomplish  the  transformation  by 
communicating  what  is  happening,  and 
why,  and  what  will  happen  if  the 
organization  is  not  successful. 

As  the  change  management  team  proceeds 
through  this  step,  the  following  questions  will  be 
asked  and  answered  several  times  as  the  nature  of 
the  impacts  on  the  current  organization  become 
better  understood: 

■  How  will  the  organization  react  to 
change,  and  what  will  be  the  basis  for 
this  reaction? 

■  Who  are  the  potential  champions  of  the 
change,  and  why  will  they  be  supportive? 


■  What  are  realistic  expectations  for  the 
organization,  and  where  will  we  have  to 
accept  compromises  both  in  process 
design  and  organizational  change? 

■  How  much  time  is  available  to  make 
changes  based  on  the  estimated  time¬ 
table  for  implementing  the  new  process? 

■  How  much  of  the  organization  (how 
many  functional  units)  will  be  subject  to 
the  change?  Should  we  target  a  single 
unit  or  attempt  to  transform  all  at  the 
same  time? 

■  How  will  we  measure  progress  and 
results?  How  will  we  know  what  success 
is? 

When  the  tasks  in  this  step  are  complete,  the 
change  management  team  will  have  produced  an 
organizational  impact  statement  that  presents  a  clear 
and  honest  picture  of  the  potential  impacts  to 
structure  and  culture  based  on  potential  process 
improvement  initiatives.  This  report  may  be 
structured  to  indicate  several  scenarios  related  to  the 
process  improvement  initiatives  eventually  adopted. 
The  change  management  team  will  also  be  able  to 
provide  the  process  improvement  team  with  one  or 
more  organizational  enablers  which  may  be  defined 
as  structural  and  cultural  strengths  that  can  be 
effectively  used  in  refining  process  design  features. 

The  following  tasks  are  performed  in  the 
Identify  Organizational  Change  Requirements  step: 

■  Review  and  evaluate  process 
improvement  analysis  report 

■  Document  organizational  best  practices 

■  Evaluate  organizational  change 
requirements 

■  Develop  time  and  cost  estimates 

■  Develop  organizational  impact  statement 

■  Review  and  approve  organizational 
impact  statement. 
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6.2.1  Review  Process  Improvement  Analysis 
Report.  This  report  produced  by  the  process 
improvement  team  in  Step  7  lays  out  a  series  of 
process  improvement  opportunities.  These 
opportunities  should  be  reviewed  and  evaluated  by 
the  change  management  team  with  respect  to  the 
current  situation  of  potentially  affected 
organizational  units. 

Each  of  the  opportunities  in  this  report  will 
have  some  potential  impact  on  organizational 
structure  and  culture.  These  impacts  should  be 
noted  and  classified.  Brainstorming,  followed  by 
classification  and  prioritization,  is  the  recommended 
technique  for  accomplishing  this  task. 

Structural  changes  will  fall  into  two 
categories:  those  that  the  affected  organizational 
units  have  the  power  to  change,  and  those  that  will 
require  involvement  by  higher  authority  to  change. 
Where  possible,  the  specific  directives  affecting  the 
structural  situation  should  be  noted. 

Cultural  changes  cannot  be  neatly  classified. 
But  change  management  teams  need  to  be  aware  of 
the  demanding  nature  of  trying  to  fiddle  with  culture 
in  an  established  organization.  Shuster^^  suggests  a 
series  of  provocative  assumptions  that  can  help 
change  management  teams  better  understand 
people,  so  that  they  can  deal  more  effectively  with 
the  cultural  issues  associated  with  process 
improvement.  With  respect  to  change  and  growth,  a 
great  many  hearts  have  been  broken  because  point 
15  below  is  not  well  understood. 

1 .  Groups  do  not  act;  people  do! 

2.  No  one  can  change  another  person’s 
mind,  but  one  can  place  others  in  an 
environment  that  enables  them  to  choose 
to  change  their  own  minds. 

3.  Obstacles  that  are  imposed  upon  us  are 
not  a  matter  of  personal  choice  and 
accountability.  Our  responses  to 
imposed  obstacles  are  generated  within 


us  [and],  therefore,  are  a  matter  of 
personal  choice  and  accountability. 

4.  Every  human  organization  is  an  organic 
system,  composed  of  interdependent 
individuals,  such  that  each  influences, 
and  is  influenced  by,  all.  The  healthiest 
organizations  are  those  whose 
individuals  are  bonded  and  integrated 
into  an  organic  community.  Members  of 
an  organic  community  are  survival 
interdependent  and  mutually  supportive. 

5.  People  are  disposed  to  resist  changing 
their  habitual  attitudes  and  behavior. 
Individual  habitual  attitudes  and 
behavior  are  addictive.  People  will  not 
change  unless,  and  until,  they  are 
psychologically  ready  to  withdraw  from 
their  addictions.  Purposeful  action  is 
required  to  enable  people  to  work 
through,  and  thereby  recover  from,  their 
addictions. 

6.  Theory  is  the  window  to  reality.  Theory 
is  driven  by  imagination.  Imagination  is 
more  important  than  knowledge. 
Workable  theory  is  empirical  [pragmatic] 
theory. 

7.  People  are  creatures  of  integrity  and 
want  to  do  a  good  job;  belong  to 
something  bigger  than  themselves;  break 
bureaucratic  chains  of  alienation; 
experience  joy  in  work;  and  be 
recognized,  trusted,  treated  with  dignity, 
and  delegated  authority  and 
accountability. 

8.  Perfection,  as  an  ideal,  is  an  acceptable 
standard  of  performance.  Perfection  can 
be  approached  incrementally.  Horizons 
of  perfection  grow  and  expand  as  they 
are  approached  with  imagination  and 
according  to  attitudes  and  events. 


22  "Making  Cultural  Change  Happen,"  H.  David  Shuster,  Quality  Management  Journal,  January  1994. 
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9.  Education  is  not  a  function  of 
conununity;  it  is  the  community. 

10.  Processes,  although  central  to 
transformation,  are  abstractions  rendered 
operational  only  by  individual  action. 

11.  No  one  can  delegate  involvement. 

12.  Commitment  means  fanatical  tmst 
in  people’s  integrity  and  obsessive 
intolerance  for  anything  less  than  the  full 
and  continuous  application  of 
management  transformation  principles 
and  practices. 

13.  It  is  not  enough  to  want  to  change; 
people  must  know  how  to  change. 

14.  Measurement  is  crucial  to  management 
transformation,  but  it  is  vital  to  know 
what,  why,  when,  where,  and  how  to 
measure.  Sometimes  the  most  important 
things  cannot  be  measured  for  example, 
the  business  lost  by  customers  who  never 
return  or  normative  assumptions  (what 
one  should/should  not  do). 

1 5 .  Never  try  to  convince  the  unconvincable. 

16.  Management  transformation  is  a 
management  philosophy  that  inspires  and 
commits  every  individual  to  visibly  and 
actively  participate  in  the  development, 
nurturing,  and  sustaining  of  a  working 
culture  that  pursues  the  ethic  of  total 
customer  satisfaction  through  dedication 
to  continuous  process  performance 
improvement. 

Shuster’s  work  needs  no  elaboration  other  than 
to  note  that  his  use  of  the  term  management 
transformation  is  roughly  equivalent  to  the  term 
organizational  change  management  as  used  in  this 
guide. 

At  this  point,  the  change  management  team 
should  have  a  workable  understanding  of  the 
potential  effects  of  the  proposed  process 
improvement  initiatives  on  the  organizational 
infrastructure. 


6.2.2  Document  Organizational  Best  Practices. 

By  this  time,  the  change  management  team  should 
understand  the  functional  units  under  study  well 
enough  to  develop  an  annotated  list  of 
organizational  best  practices. 

The  concept  best  practices  is  used  in  the  sense 
of  identifying  those  things  that  one  or  more 
functional  units  do  well  (with  respect  to  structure 
and  culture),  which  should  be  leveraged  in  any 
process  improvement  effort.  These  things  can  also 
be  called  enablers  of  process  improvement  and 
should  be  communicated  to  process  improvement 
team  members.  This  is  important  because  a  process 
improvement  team  may  not  be  aware  of  a  best 
practice  in  a  functional  unit  not  included  in  the 
process  improvement  project. 

Examples  of  organizational  best  practices  can 
be  found  in  any  of  the  following  categories: 

■  Leadership  practices 

■  Motivational  practices 

■  Training  practices 

■  Organizational  structures 

■  Reward  and  recognition  systems 

■  Communication  systems 

6.2.3  Evaluate  Organizational  Change 
Requirements.  With  the  information  gathered  and 
analyzed  to  this  point,  the  change  management  team 
begins  to  evaluate  the  need  for  specific 
organizational  change  initiatives.  These 
organizational  changes  (initiatives  and  programs) 
are  directly  related  to  specific  process  changes  that 
are  being  designed  by  the  process  improvement 
team. 

These  questions  can  be  used  to  evaluate  each 
potential  change  management  requirement: 

■  What  is  the  situation  in  the  proposed 
process  that  indicates  a  need  for  an 
organizational  change  or  institution  of  a 
new  practice? 

■  What  factors  are  involved  in  this 
situation? 
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■  Who  wants  the  change  to  occur  and 
why?  What  are  the  prime  motives? 

■  Are  these  motives  consistent  with,  or  in 
opposition  to,  established  policy  and 
cultural  factors?  Has  the  possibility  of 
conflict  with  current  policy  been  fully 
explored? 

■  Who  can  be  counted  on  to  support  the 
change  effort,  and  why  and  how  will 
they  support  it? 

■  Who  will  probably  resist  the  change 
effort,  and  what  will  be  their  basis  for 
resistance? 

■  Will  higher  authority  support  the 
proposed  changes? 

When  these  questions  have  been  asked  and 
answered  for  each  significant  organizational  change 
proposal,  the  situation,  supporting  facts,  and  the 
approach  to  implementing  the  change  should  be 
written  out  in  the  form  of  a  preliminary  plan. 

At  this  point,  the  change  management  team 
will  have  one  or  more  synopses  of  potential 
organizational  changes,  adjustments,  improvement, 
initiatives,  innovations,  and  programs  directly 
associated  with  potential  process  improvement 
initiatives. 

6.2.4  Develop  Time  and  Cost  Estimates.  The 
timeframe  and  estimated  costs  (level  of  effort)  are 
developed  for  each  of  these  change  management 
initiatives.  The  assumed  benefit  of  the  change 
initiative  is  that  is  supports  a  proposed  process 
improvement  initiative.  Once  the  estimated  level  of 
effort  is  known,  the  change  management  team  can 
work  with  the  process  improvement  team  to 
validate  and  rationalize  the  overall  set  of  process 
and  organizational  changes  and  improvements. 

6.2.5  Develop  Organizational  Impact  Statement. 

It  is  now  possible  to  develop  an  organizational 
impact  statement  (OIS)  for  each  set  of  change 
initiatives.  Like  its  forerunner,  the  environmental 
impact  statement,  the  OIS  examines  the  overall 
affect  of  disrupting  the  status  quo  with  respect  to 


process  improvement.  The  OIS  attempts  to  describe 
collateral  effects  in  functional  units  that  may  not 
directly  benefit  from  the  proposed  process 
improvement  but  will,  nevertheless,  will  be  affected 
by  it.  For  instance,  a  change  management  initiative 
may  recommend  a  just-in-time  training  program 
that  may  tax  the  existing  training  department. 

The  following  questions  can  be  asked  in 
developing  the  OIS: 

■  What  individuals  and  groups  (functional 
units)  will  be  affected? 

■  How  severe  will  this  impact  be? 

■  How  will  they  be  involved  in  the  change 
(labor  hours,  costs,  disruption,  etc.)? 

■  How  will  they  benefit  from  the  change 
and  will  this  be  an  immediate  or  long¬ 
term  benefit?  Will  significant  costs  be 
incurred  in  the  short  term  for  a  benefit 
that  will  not  be  realized  in  the  current 
budget  cycle? 

■  Will  they  ultimately  gain  or  lose 
resources? 

■  Will  they  gain  or  lose  power,  positions, 
prestige,  work,  customers,  or  suppliers? 

■  What  are  the  tradeoffs  for  any  losses? 

6.2.6  Review  and  Approve  Organizational 
Impact  Statement.  The  OIS  is  submitted  to  higher 
authority  for  review,  validation,  and  approval.  Due 
to  the  subjective  nature  of  the  OIS,  it  is  probable 
that  the  issues,  analysis,  and  conclusions  reached 
will  have  to  be  explained  or  defended.  For  this 
reason,  the  change  management  team  should  ensure 
that  backup  documentation  is  available  to  justify  the 
analysis. 

The  OIS  should  also  contain  a  catalog  of 
organizational  enablers  for  process  improvement 
that  may  influence  the  final  design  for  processes 
undergoing  improvement.  These  enablers  are 
strengths  that  should,  if  possible,  be  leveraged  in  the 
new  design. 
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6.3  Step  12:  Develop  Organizational  Change 

Management  Plan 

After  the  impact  statement  has  been  reviewed 
and  the  process  improvement  team  has  completed 
Step  8,  Redesign/Reengineer  Process,  the  formal 
change  management  plan  can  be  completed.  The 
organizational  change  management  plan  will  be  one 
of  the  inputs  to  enterprise  engineering  along  with 
the  FEA  and  technical  change  management  plan.  It 
will  be  the  role  of  the  process  improvement  team 
during  the  enterprise  engineering  phase  to  integrate 
all  three  change  plans. 

The  formal  plan  for  instituting  organizational 
changes  must  include  a  strategy  for  overcoming 
structural  barriers  and  human  resistance  to  change. 
The  plan  should  also  include  a  synopsis  of  likely 
staffing,  training,  and  development  requirements. 

The  following  tasks  are  performed  in  this  step: 

■  .  Analyze  organizational  barriers  to 

change 

■  Prepare  strategies  for  overcoming 
barriers 

■  Identify  process-related  training 
requirements 

■  Develop  organizational  change 
management  plan 

■  Review  and  approve  organizational 
change  management  plan. 

6.3.1  Analyze  Organizational  Barriers  to 
Change.  Barriers  to  change  may  be  classified  into 
three  general  categories: 

■  Structural 

■  Cultural 

■  Regulatory. 

Each  category  must  be  handled  differently. 
Structural  barriers  are  imposed  either  within  the 
organization  itself  or  by  higher  authority. 
Surprisingly,  functional  organizations  often  lose 
track  of  the  limits  and  barriers  they  place  on 
themselves,  and  fail  to  realize  that  they  have  the 
authority  to  make  meaningful  changes. 


Barriers  imposed  by  higher  authority  are  more 
difficult  to  deal  with.  A  business  case  should  be 
developed  that  justifies  the  need  to  eliminate  or 
moderate  these  types  of  barriers. 

Cultural  barriers  are  the  result  of  ingrained 
practice,  a  form  of  on-the-job  training  as  it  were. 
Cultural  barriers  have  to  be  understood  in  the 
context  of  Shuster’s  assumptions  given  in  the 
previous  step. 

Regulatory  barriers  (public  law,  regulations, 
higher  headquarters  policy,  etc.)  require  a  major 
effort  to  change.  The  change  process  may  take 
years  if  it  happens  at  all.  The  change  management 
team  must  always  have  a  fall-back  position  with 
respect  to  regulatory  barriers.  Suboptimization  due 
to  regulatory  barriers  should  be  documented  and 
transmitted  to  higher  authority  for  consideration. 

Some  of  the  barriers  conunon  within  DoD 
include  the  following: 

■  Senior  leadership  commitment  and  buy- 
in:  Business  process  reengineering  is  a 
top-down  initiative  and  depends  upon 
strong  leadership  to  overcome  obstacles. 

■  Focus  on  current  operations:  Process 
improvement  dismpts  established 
procedure  and  challenges  existing 
regulations  and  directives.  Management 
must  successfully  guide  employees 
through  the  transition  period  from 
existing  process  to  reengineered  process. 

■  Becoming  customer  centered:  Managers 
and  employees  must  shift  from  a  rule- 
based  to  a  customer-based  mode  of 
operation  and  establish  performance 
measures  that  focus  on  process  outcomes 
rather  than  process  inputs  such  as  budget. 

■  Aversion  to  job  elimination,  risk,  and 
change:  The  very  essence  of  process 
improvement  is  the  elimination  of  non¬ 
value  activities,  radical  change,  and 
adoption  of  high-technology  solutions — 
all  of  which  challenge  the  organizational 
status-quo. 
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■  Mismatch  between  authority  and 
responsibilities:  Process  improvement 
includes  the  concept  of  team-based 
performance  and  worker  empowerment, 
both  of  which  challenge  traditional 
management  and  organizational  wisdom. 

■  Functional  and  technical  stovepipes: 

The  concept  of  process  crosses 
established  organizational  boundaries 
and  requires  new  methods  of  managing 
work  products. 

■  Inconsistent  rules,  methods,  and 
techniques  underlying  management 
processes:  Many  of  the  non-value  added 
activities  associated  with  processes 
undergoing  improvement  are  traceable  to 
obsolete  or  inappropriate  rules, 
regulations,  methods,  and  techniques 
whose  worth  must  be  reevaluated. 

■  Policies  on  job  descriptions,  training, 
and  reassignment:  Process  improvement 
calls  for  a  radical  reengineering  of 
personnel  policies  that  currently  limit  the 
authority  of  management  to  develop  a 


flexible,  customer-centered  work  force 
with  appropriate  rewards  and  recognition 
for  team-centered  performance  and 
individual  skill  development. 

■  Funding:  Current  funding  practices 
support  the  status  quo  and  inhibit 
management’s  ability  to  apply  scarce 
resources  to  activities  that  produce 
products  and  services  most  needed  by 
internal  and  external  customers. 

All  barriers  identified  in  previous  steps  should 
be  classified  and  analyzed  so  the  all  assumptions 
and  facts  relating  to  each  barrier  can  be  properly 
analyzed. 

With  respect  to  any  kind  of  change,  there  are 
generally  two  groups  of  people  involved:  those 
who  are  sponsors  of  change  (want  the  change)  and 
those  who  are  the  targets  of  change  (resist  the 
change,  at  least  initially).  Carr  and  Littman^^ 
suggest  a  matrix  approach  to  help  understand  how 
to  approach  the  task  of  overcoming  barriers. 

Figure  6-3  illustrates  this  approach. 
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Figure  6-3.  Analyzing  Barriers 


23  Excellence  in  Government,  David  K.  Carr  and  Ian  D.  Littman,  Coopers  &  Lybrand,  1990. 
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Figure  6-3  is  a  matrix  illustrating  four 
situations  involving  sponsors  of  change  and  targets 
of  change.  The  grids  indicate  the  relative  degree  of 
risk  versus  opportunity  with  respect  to  sponsors  and 
targets  and  the  change  issue. 

For  issues  that  map  into  quadrant  1  (high 
opportunity  for  both  sponsors  and  targets),  change 
management  is  relatively  simple.  The  change 
should  be  received  well  and  the  necessary  resources 
for  successful  implementation  provided. 

For  issues  that  map  into  quadrant  2  (high 
opportunity  for  targets  and  high  risk  for  sponsors), 
this  is  little  chance  that  the  change  will  be  accepted, 
or  successful  if  it  is.  The  remedies  are  to  educate  or 
replace  sponsors,  or  prepare  for  failure.  It  may 
seem  odd  that  a  sponsor  would  resist  the  change. 
This  is  an  example  of  “lip-service”  where  sponsors 
may  say  they  want  the  change  but,  in  reality,  they 
don’t. 

For  issues  that  map  into  quadrant  3,  there  is  no 
hope  of  proceeding  with  the  change.  Failure  is 
assured. 

For  issues  that  map  into  quadrant  4,  the 
changes  can  be  forced,  but  at  great  expense.  For 
instance,  many  regulations  and  mandates  fall  into 
this  quadrant. 

6.3.2  Prepare  Strategies  for  Overcoming 
Barriers.  The  general  approach  to  dealing  with 
change  management  is  to  strive  to  develop  and 
associate  opportunities  and  rewards  for  both 
sponsors  and  targets  for  every  change  management 
issue. 

Another  technique  is  to  use  force  field 
analysis.  Force  field  analysis  is  described  in 
Section  10  of  this  guide.  This  technique  graphically 
illustrates  the  forces  lined  up  in  support  of  a 
proposition  (a  change  in  this  case),  and  the  forces 
lined  up  in  opposition  to  the  proposition.  Once  the 
array  of  forces  is  understood  and  matched  head-to- 
head,  strategies  for  removing  the  most  important 
negative  forces,  and  reinforcing  the  most  positive 
forces  can  be  developed.  Force  field  analysis  helps 
the  change  management  team  win  the  war  at  the 


possible  expense  of  losing  a  battle  or  two.  The 
technique  is  a  great  help  in  preparing  for 
negotiations  and  issue  resolving  conferences. 

Carr  goes  on  to  suggest  three  additional 
strategies  to  be  used  in  sequence  for  influencing  the 
target  population  to  accept  and  support  a  change 
proposition. 

■  Wedge  strategy,  which  is  designed  to 
convince  targets  that  the  AS-IS  situation 
is  no  longer  desirable: 

—  Explain  the  problems  and 
opportunities 

—  Validate  that  the  old  way  worked  in 
times  past 

—  Present  the  vision  for  the  change 
—  Specify  the  necessary  changes 
—  Make  it  uncomfortable  to  continue 
resistance. 

■  Transition  strategy,  which  initiates 
change  and  builds  momentum  for 
continuing  with  it: 

—  Reinforce  why  the  change  is 
necessary 

—  Look  for  opportunities  to  gain 
small  successes 

—  Provide  accurate  and  timely 
supporting  information 
—  Involve  the  target  in  planning 
actions 

—  Allow  the  target  to  ventilate  minor 
grievances 

—  Focus  on  the  future  state — the 
vision 

_  Reward  those  who  support  the 
change  process 
_  Assign  targets  to  key 
responsibilities 

—  Provide  targets  with  resources  to 
facilitate  the  change  process. 

■  Magnet  strategy,  which  focuses  targets 
away  from  the  transition  state  and  on  the 
future  state: 
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—  Show  sponsor  commitment 
—  Increase  rewards  for  moving 
forward 

—  Make  it  easier  to  move  toward  the 
change  than  to  stay  in  place  or 
regress. 

When  this  task  is  complete,  the  change 
management  team  should  have  a  well-developed 
plan  and  strategy  for  dealing  with,  overcoming,  or 
sidestepping  all  barriers  to  organizational  change 
management. 

6.3.3  Identify  Process-related  TValning 
Requirements.  The  chief  enabler  at  successful 
organizational  change  is  a  well-conceived  training 
program  that  is  ongoing  over  the  entire  change 
period.  Initial  training  will  focus  on  awareness, 
attitude  adjustment,  and  concepts.  As  the  project 
nears  the  implementation  phase,  training  will  begin 
to  focus  on  skill  development. 

The  responsibility  of  the  change  management 
teana  is  to  identify  the  training  requirements  with  as 
much  specificity  as  possible  with  respect  to  learning 
objectives,  job  skills,  competencies,  training 
audience  categories,  estimated  number  of  students 
by  category,  and  timeframe.  With  this  information, 
training  support  personnel  can  work  with  change 
management  team  members  and  functional  sponsors 
to  develop  or  acquire  the  required  training  courses. 
Section  12  of  this  guide  has  more  information  on 
training  support. 

6.3.4  Develop  Organizational  Change 
Management  Plan.  The  change  management  plan 
should  be  developed  according  to  the  following 
outline: 


■  Change  requirement  and  description 

■  Objectives  and  goals  expressed  in 
performance  terms 

■  Action  plan  for  achieving  the  objective 
with  schedules  and  milestones 

■  Resource  allocation  plan  for  supporting 
the  change  process 

■  Communications  plan 

■  Issue  resolution  plan. 

The  change  management  plan  will  be  a 
synthesis  of  all  the  change  elements  developed  in 
tandem  with  the  process  improvement  team.  As  the 
improvement  project  moves  into  the  enterprise 
engineering  phase,  the  change  management  team 
will  monitor  progress  and  make  changes  and 
adjustments  as  necessary.  As  possible,  the  training 
plan  should  be  included  in,  and  synchronized  with, 
the  change  management  plan. 

6.3.5  Review  and  Approve  Organizational 
Change  Management  Plan.  This  plan  like  all 
others  is  forwarded  to  higher  authority  for  review 
and  approval.  Unlike  many  of  the  other  plans 
though,  this  one  will  be  continuously  revised  and 
updated  as  the  process  improvement  project  moves 
through  the  enterprise  engineering  and  project 
execution  phases.  Once  the  plan  is  approved  by 
higher  authority,  it  becomes  part  of  the  input  to  the 
enterprise  engineering  phase. 
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Addendum 

Figure  6-4  shows  examples  of  cultural 
changes  derived  from  a  DoD  publication.  The  DoD 
publication  that  this  figure  is  based  on  is  not  known. 
The  figure  was  reproduced  in  Excellence  in 
Government,  by  David  K.  Carr  and  Ian  D.  Littman. 


Category 

New  Culture 

Mission 

Maximum  return  on  investment 

Ethical  behavior  and  customer 

Management  by  objectives 

satisfaction;  continuous 
improvement 

Customer 

Incomplete  understanding  of 

Systematic  approach  to  satisfy 

requirements 

customer  requirements 

internal/external  customers 

Suppliers 

Unidirectional  relationship 

Partnership 

Objectives 

Short-term  objectives  with  limited 

Long-term  goals;  Short-term 

long-term  perspective 

objectives 

Improvement 

Acceptance  of  variability; 

Understanding  and  continually 

Assigning  blame  the  norm 

improving  the  process 

Problem 

Unstructured  individualistic 

Participatory  an  cross-functional 

solving 

problem  solving/decision  making 

problem  solving/decision  making 

Job  and 

Functional,  narrow  scoped; 

Work  teams,  integrated 

people 

management  controlled 

functions;  cooperation 

Management 

Uncertain  objectives  which  instills 

Open  style,  clear  objectives. 

style 

fear  of  failure 

encourage  teamwork 

Role  of 

Plan,  organize,  assign,  control. 

Communicate,  consult,  delegate. 

manager 

and  enforce 

coach,  remove  barriers 

Rewards  and 

Pay  by  job;  few  team  incentives 

Individual  and  group  recognition 

recognition 

and  rewards,  negotiated  criteria 

Measurement 

Orientation  toward  data  gathering 

Data  used  to  understand  and 

or  problem  identification 

continuously  improve  process 

Figure  6-4.  DoD  Examples  of  Cultural  Changes 
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SECTION  7.  PHASE  2C:  TECHNOLOGY  CHANGE  MANAGEMENT 


While  many  useful  and  rewarding  process 
improvements  can  be  achieved  apart  from  any 
consideration  of  technology  enablers  or  information 
system  betterments,  true  or  radical  reengineering 
efforts  invariably  depend  on  exploitation  of  available 
or  emerging  information  technology  capabilities. 

The  effective  use  of  advanced  technology  can 
dramatically  enhance  an  organization’s  ability  to 
achieve  major  or  even  breakthrough  improvements 
in  all  four  measurement  categories. 

■  Fitness-for-Purpose  -  Technology 
provides  the  means  to  deliver  superlative 
customer  service  by  enabling 
organizations  to  easily  and  inexpensively 
customize  services  and  products  that  will 
match  exact  customer  needs  and 
requirements. 

■  Conformance-to-Standard  -  Technology 
enaWes  the  achievement  of  exacting 
quality  standards  resulting  in  dramatic 
decreases  in  error  rates,  rejects,  and 
waste. 

■  Process  Cycle  Time  -  Employing 
technology  is  virtually  the  only  way  to 
reduce  the  operational  time  it  takes  to 
produce  a  unit  of  output.  Advanced 
technology  makes  it  possible  to  automate 
production  while  delivering  seemingly 
customized  products  and  services. 

■  Process  Costs  -  While  employing  new 
technology  always  requires  initial 
investment  and  start  up  costs  (as  well  as 
risk),  the  return  on  investment  can  often 
be  measured  in  orders  of  magnitude, 
especially  in  service-based  processes. 

Technology,  carefully  evaluated,  prudently 
selected,  and  wisely  implemented,  enables  radical 
business  process  reengineering.  The  key  word  is 
enables.  This  means  that  technology  is  not 
something  that  is  considered  after  processes  are 
reengineered.  Rather,  consideration  of  technology 
capability  drives  the  development  of  the  new  process 


design.  Therefore,  the  time  to  consider  technology 
issues  begins  with  process  visioning,  continues 
through  process  redesign  (constmction  of  the  TO- 
BE  model),  and  becomes  a  major  component  of  the 
Functional  Economic  Analysis  (FEA)  decision 
package. 

The  other  side  to  technology  consists  of  the 
existing  technological  platform  that  supports  current 
business  processes.  While  it  is  possible  that  current 
capability  is  not  fully  utilized  to  support  process 
requirements,  it  is  more  probable  that  existing 
technology  is  obsolete  and  a  detriment  to  process 
improvement.  In  this  case,  existing  technology 
represents  a  barrier  to  process  improvement  that 
must  be  overcome  just  like  organizational  barriers 
exist  to  thwart  process  improvement  efforts. 

It  is  not  always  easy  or  even  possible  for 
functional  elements  to  distinguish  enabling 
technology  from  inhibiting  technology.  There  are 
issues  of  technology  integration,  migration  or 
transitional  systems,  interoperability,  and 
compatibility  that  are  well  within  the  realm  of  the 
technical  elements.  Such  issues  are  best  handled 
during  the  enterprise  engineering  phase  of  the 
Framework  Methodology.  Functional  elements 
must  focus  on  what  they  want  in  terms  of 
technological  capability  expressed  in  terms  of 
measures,  then  let  the  technical  elements  decide 
how  to  achieve  the  desired  results.  If  existing 
technology  can  be  reworked  or  reconfigured  to 
obtain  these  results,  so  much  the  better. 

There  are  also  the  elements  of  cost  and  risk 
that  must  be  addressed  with  respect  to  technology. 
That  a  technological  investment  may  return  many 
times  its  investment  becomes  moot  if  the  initial 
investment  funds  cannot  be  obtained.  Intolerance 
for  high  risk  may  prohibit  an  investment  in  new 
technology  even  if  the  funds  are  available  or  could 
be  made  available.  Functional  managers  will  call 
upon  the  services  of  financial  analysts  and 
engineering  consultants  to  aid  in  making  investment 
decisions. 
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Finally,  technology  change  management  must 
be  integrated  with  organizational  change 
management,  and  both  must  be  compatible  with  the 
objectives  of  the  redesigned  business  process.  New 
technology  is  often  frightening  to  employees  and 
managers  alike.  There  is  both  a  learning  curve  and 
an  acceptance  curve.  Since  most  people  cannot 
accept  something  they  don’t  understand,  and  will 
not  learn  something  they  don’t  accept;  these  curves 
must  be  traveled  in  parallel,  and  the  journey  is  not 
usually  as  smooth  or  as  fast  as  we  would  like.  And 
some  people  may  never  arrive  at  the  desired 
destination. 

Existing  rules  and  regulations  may  be  more  of 
a  barrier  to  technology  insertion  than  organizational 
or  cultural  issues.  Rules  and  regulations  are 
oriented  to  a  command  and  control  working 
environment,  while  many  of  the  emerging 
technologies  are  designed  to  enable  empowered 
work  teams  to  focus  on  serving  customer 
requirements.  Empowered  work  teams  depend 
upon  a  free  flow  of  information  across  the  business 
process  and  increased  accountability  and  decision 
making  authority.  Functional  managers  engaged  in 
process  reengineering  must  work  with  higher 
authority  early  in  the  process  redesign  effort  to 
ensure  that  overly  restrictive  (or  obsolete)  rules  and 
regulations  are  suitably  adapted  in  line  with  planned 
technology  capability.  There  are  numerous 
examples  of  situations  where  new  process  designs 
had  to  be  intentionally  crippled  so  that  the  process 
operations  could  conform  to  rules  and  regulations 
that  no  longer  provide  customer  or  business  value- 
added  benefits. 

Current  technology  capability  invalidates 
much,  but  not  all,  of  the  rationale  behind  functional 
or  stovepipe  organizational  structures.  Apart  from 
the  technological  capability  that  now  exists,  there 
was  no  reasonable  way  in  the  past  to  manage  work 
in  large  organizations  other  than  through  the 
functional  model.  That  the  terms  cross-functional 
work  teams,  or  concurrent  engineering,  or  computer 
integrated  manufacturing  even  exist  is  an 
acknowledgement  that  we  now  structure  work 
around  current  organizational  impediments  and 
accomplish  results  in  spite  of  the  functional 
orientation  that  still  thrives  in  most  large 
organizations. 


It  is  clear  that  the  forces  of  change  are  moving 
organizations  irrevocably  toward  a  horizontal  or 
process  management  orientation.  It  is  also  clear 
that  technology  is  the  change  engine  behind  this 
movement,  since  it  is  technology  that  makes  the 
new  work  paradigm  possible.  Furthermore,  people 
do  not  willingly  abandon  that  which  they  have 
prospered  from  (in  this  case  functional  management 
structures)  apart  from  crisis.  This  represents  a 
strong  argument  to  consider  not  only  the  process 
improvement  potential  of  technology  insertion  but 
also  its  potential  to  disrupt  the  organizational  status 
quo.  In  other  words,  technology  insertion  is  far 
from  being  solely  a  technical  or  cost  consideration. 
The  human  and  organizational  issues  of  technology 
insertion  must  be  considered  fully  and  in  tandem 
with  the  pure  capability  or  cost  issues. 

Before  relating  the  methodology  steps  in  this 
phase  of  the  Framework  Methodology,  it  is 
important  to  establish  the  overall  objectives  of 
considering  technology  as  an  enabler  of  business 
process  reengineering.  There  appear  to  be  three 
major,  time-phased  objectives  in  the  new 
organizational  paradigm  that  depend  in  large 
measure  on  the  effective  use  of  technology  enablers: 

■  Creating  high-performance,  cross¬ 
functional  work  teams  focused  on 
providing  quality  and  service  to  both 
internal  and  external  customers. 

■  Establishing  a  highly  integrated 
enterprise  centered  around  core  business 
processes  supported  by  interoperable 
information  systems  and  enterprise-wide 
shared  data. 

■  Achieving  the  attribute  of  the  virtual 
corporation  or  extended  enterprise  made 
up  of  intimate  (but  flexible)  supplier  and 
customer  partnerships  that  are  intensely 
customer  driven  and  highly  responsive  to 
any  changes  in  the  external  environment 
whether  those  changes  are  socio¬ 
economic,  geo-political,  market-oriented, 
or  competitive. 
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It  should  be  clear  that  these  overriding 
objectives  are  sequential.  It  is  not  possible  to 
achieve  the  state  of  being  a  virtual  corporation 
unless  the  enterprise  is  well  integrated  internally. 
And  it  is  not  possible  to  do  that  unless  the  restraints 
of  the  functional  straightjacket  are  loosened  via  the 
creating  of  empowered  work  teams.  It  should  also 
be  clear  that  not  all  enterprises  will  move  through 
this  progression  at  the  same  time  or  at  all.  But  it  is 
difficult  to  see  how  any  enterprise  will  continue  to 
exist  if  it  remains  resistant  to  achieving  even  the 
first  objective  in  this  progression. 

Since  these  objectives  do  represent  a 
progression,  and  most  organizations  embarking  on 
reengineering  efforts  have  not  yet  fully  achieved  the 
first  one,  this  phase  of  the  Framework  Methodology 
is  focused  on  using  technology  enablers  to  achieve 
the  objective  of  establishing  high-performance, 
cross-functional  work  teams. 

The  objectives  for  establishing  a  work  team 
concept  are  the  following  (with  an  emphasis  on  the 
technology  implications): 

■  Restructure  business  processes  to  enable 
work  sharing  by  providing  streamlined 
communications  and  information  on 
demand 

■  Eliminate  unproductive  (non- value 
added)  activities  due  to  excessive 
oversight  that  can  be  replaced  with  more 
controls  being  integrated  into  work 
processes 

■  Establish  work  group  computing  that 
enables  teams  to  collaborate  on  the 
creation  of  woik  products  including 
products,  documents,  specifications,  and 
designs  utilizing  all  available  media: 
text,  data,  voice,  graphics,  and  images 

■  Institute  a  more  efficient  division  of 
labor  using  such  technological  tools  as 
work  flow  analysis,  groupware,  office 
automation,  document  creation  software, 
and  other  productivity  tools 


■  Increase  information  flows  and  data 
sharing  across  business  processes  to 
lessen  the  effects  of  hierarchical  or 
functional  segmentation 

■  Improve  decision  making  capability  by 
providing  rule-based  decision  support 
tools  and  expert  systems  capability. 

The  technological  platform  or  infrastructure 
must  support  all  business  processes,  not  just  the 
particular  process  being  redesigned.  It  is  the  job  of 
the  technical  change  management  team  to  mediate 
between  the  technical  elements  responsible  for  the 
technical  infrastructure  and  the  process 
improvement  team  to  ensure  that  technology 
changes  or  insertions  do  not  disrupt  overall 
operations. 

At  the  conclusion  of  this  phase,  the  technical 
change  management  team  will  have  produced  a  plan 
that  aligns  process  improvement  with  potential 
technology  enablers  and  addresses  known 
technological  barriers  to  implementing  redesigned 
processes.  The  results  will  be  incorporated  into  the 
Functional  Economic  Analysis  decision  support 
package.  As  the  improvement  project  moves 
through  the  enterprise  engineering  and  project 
execution  phases,  the  change  management  team  will 
coordinate  technology-based  actions  with  process 
improvement  actions. 

The  technical  change  management  phase  of 
the  Framework  for  Managing  Process  Improvement 
is  supported,  in  part,  by  the  following  resources: 

■  F/MPI  Management  Briefing  on 
Technical  Change  Management 

■  F/MPI  Technical  Change  Management 
Tlitorial 

The  techniques  (described  in  Section  10)  most 
useful  in  this  phase  include  the  following: 

■  Benchmarking  (best  practices) 

■  SWOT  Analysis 

■  Cause  and  Effect  Diagram 

■  Force  Field  Analysis 
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■  Pareto  Analysis 

■  Economic  Analysis 

7.1  Step  13:  Assess  Technical  Capability 

Streamlining  business  processes  by 
eliminating  non- value  activities  and  costs  (picking 
the  low-hanging  fruit)  can  be  accomplished  apart 
from  technical  considerations.  But  beyond  that 
process  improvement  level,  it  is  critical  for  the 
process  improvement  team  to  understand  the  status 
of  the  current  technical  assets  that  support  the 
targeted  business  process.  This  data  provides  a 
baseline  from  which  to  plan,  design,  and  acquire 
technical  betterments  that  will  enable  or  support 
process  improvement  efforts. 

Once  the  change  management  team 
understands  the  strengths  and  weaknesses  of  the 
existing  technological  plant,  it  becomes  easier  to 
identify  and  categorize  potential  technological 
changes.  In  this  context,  technology  can  include 
platforms,  applications,  information  systems,  and 
communications  systems  of  aU  types.  The  most 
expedient  classification  scheme  would  place  these 
assets  in  one  of  four  categories: 

■  Existing  technology  is  adequate  and  will 
support  potential  process  improvement 
efforts 

■  Existing  technology  needs  upgrades  to 
support  potential  process  improvement 
efforts 

■  Existing  technology  is  obsolete  and  must 
be  replaced 

■  There  is  no  existing  technology  of  the 
type  required  to  support  potential  process 
improvement  efforts. 

When  the  tasks  in  this  step  are  complete,  the 
change  management  team  will  be  positioned  to 
identify  and  prioritize  a  series  of  technological 
changes  needed  to  support  planned  process 
improvements. 

The  following  tasks  are  performed  in  the 
assess  technical  capability  step: 


■  Review  Process  Improvement  Plan 
Technical  Implications 

■  Assess  Current  Technical  Status 
(Strengths/Weaknesses) 

■  Assess  Emerging  Technologies  v  Process 
Requirements 

■  Document  Technical  Status 

■  Review  and  Approve  Status  Report 

7.1.1  Review  Process  Improvement  Plan 
Technical  Implications.  At  various  checkpoints  in 
the  reengineering  phase,  the  change  management 
team  should  pause  to  evaluate  the  technical 
implications  inherent  in  evolving  process  redesign 
elements.  Many  of  these  elements  were  introduced 
in  Section  5.2.10  Identify  and  Document 
Technology  Issues.  Each  potential  technology 
change  or  insertion  needs  to  be  reviewed  in  terms  of 
the  existing  information  technology  architectures. 
This  can  be  a  difficult  task  because  of  the  natural 
change  resistance  factors  that  will  be  present  in  the 
technical  organizations. 


■  Change  the  way  data  and  information  is 
collected,  entered  into  systems,  filed  and 
referenced?  Will  document  scanners 
replace  key  entry?  Will  bar  coding  be 
used  to  track  material  and  documents? 
Will  single  point  of  entry  sourcing  be 
used? 

■  Require  new  or  different  processing 
algorithms  such  as  if-then-else  rale- 
based  systems,  fuzzy  logic,  object 
oriented  procedures? 

■  Need  new  decision-making  techniques  or 
software  such  as  information-, 
knowledge-,  experience-,  or  intuition- 
based  systems? 

■  Make  use  of  emerging  document 
managing  systems  that  provide 
sophisticated  techniques  for  capturing 


Some  of  the  considerations  the  change 
management  team  should  address  are  listed  below. 
The  question  to  be  asked  and  answered  (with 
respect  to  the  current  infrastructure)  is — ^will  the 
potential  process  improvement: 
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and  producing  integrated  text,  data, 
image  information?  Will  laser  generated 
forms  replace  standard  print  forms? 

■  Provide  paper-less  procedures  to  replace 
paper-intensive  business  procedures? 
Will  data  be  encoded  using  magnetic 
strips,  bar  codes,  smart  cards,  or  optical 
devices? 

■  Depend  on  integrated  text,  data,  voice, 
graphic,  and  imaging  systems  for  any 
part  of  the  design? 

■  Require  relational  data  bases,  repository 
systems,  re-use  libraries,  or  sophisticated 
keyword-in-context  retrieval  systems? 

■  Incorporate  distributed  computing 
principles  such  as  wide-area  data 
communications,  satellite 
communications  links,  video 
teleconferencing,  e-mail,  or  remote 
access  to  data  bases? 

■  Use  work  flow  or  work  group  computing 
techniques  to  support  empowered  cross¬ 
functional  work  teams? 

■  Depend  upon  networked  software  such 
as  groupware,  computer-aided  drafting 
and  design  software,  meeting  or 
conference  facilitating  software? 

■  Incorporate  sophisticated  security, 
access,  and  accountability  algorithms  to 
monitor  or  control  business  related 
decision  making? 

■  Require  graphic  user  interface  (GUI) 
software,  customized  computers  or 
interface  equipment,  analogue  to  digital 
transducers,  built-in  measuring  or 
monitoring  devices? 

■  Self-learning  systems  with  built-in  menu, 
help,  hypertext,  and  other  learning  aids? 

The  list  above  is  far  from  exhaustive  and 
obsolete  the  day  it  is  written,  but  it  does  convey  the 


importance  of  having  a  change  management  team 
monitor  process  improvement  efforts  on  a  continual 
basis  to  identify  the  implications  of  potential 
technology  enablers  for  process  improvement. 

Each  potential  enabler  must  be  considered  in 
light  of  the  existing  technological  base  and  the 
impact  such  technology  could  have  on  the  existing 
base.  This  process  ultimately  contributes  reliable 
data  that  can  be  used  in  the  decision-making  process 
that  determines  the  feasibility  of  acquiring  new 
technology  in  support  of  improvement  objectives. 

7.1,2  Assess  Current  Technical  Status 
(StrengthsAVeaknesses).  The  information  systems 
or  information  technology  organization  in  every 
large  enterprise  is  always  a  work  in  process.  At  any 
point  in  time,  there  are  systems  operating  beyond 
their  useful  life  cycle,  productive  systems  doing 
their  intended  job,  high-maintenance  systems  barely 
keeping  up  with  business  requirements,  systems 
being  developed,  systems  being  shutdown,  and  new 
systems  being  installed.  Few  organizations  will 
admit  to  having  up-to-date  architectures,  systems 
templates,  and  sound  configuration  management 
documentation.  Tracking  information  technology 
assets  is  a  formidable  task  in  large  organizations 
with  geographically  dispersed  facilities. 

With  this  in  mind,  it  is  still  important  to 
understand  the  strengths  and  weaknesses  of  the 
current  technological  infrastructure  in  organizations 
with  extensive  business  processing  projects 
underway.  (Strengths  represent  potential  process 
improvement  enablers  that  may  suffice  for 
supporting  meaningful  process  improvements.) 

This  often  happens  when  technology  developed  to 
support  one  area  of  the  business  can  be  readily 
adapted  to  support  other  areas. 

Weaknesses  represent  barriers  to  process 
improvement  that  may  set  limits  on  how  much 
improvement  can  be  accomplished  without 
substantial  investments  in  new  technology  or 
redeveloped  information  systems.  Weaknesses  are 
often  represented  by  legacy  systems  built  on 
yesterday’s  technology  that  still  serve  vital  business 
purposes.  Years  of  poorly  documented  maintenance 
actions  may  make  it  impossible  to  replace  such 
systems  one  component  at  a  time. 
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Whatever  the  situation,  it  is  important  to  fully 
evaluate  the  strengths  and  weaknesses  of  the 
existing  technological  plant  with  respect  to  new 
technology  that  may  be  required  to  support  potential 
business  process  improvements.  This  analysis 
should  extend  to  the  capabilities  of  the  technical 
staff  to  support  desired  improvements  as  well  as 
their  capacity  to  do  so  in  light  of  current  and 
continuing  responsibilities  and  assignments.  The 
technical  divisions  invariably  represent  a  bottleneck 
that  restricts  the  amount  of  technical  support 
available  for  process  improvement  efforts.  This  is 
not  a  criticism,  merely  a  fact.  It’s  been  said  that 
making  major  changes  to  the  technical 
infrastructure  is  equivalent  to  rebuilding  an  airplane 
while  it  is  still  flying.  This  is  in  recognition  of  the 
fact  that  computer  operations  cannot  be  shut  down 
to  incorporate  major  changes. 

7.1.3  Assess  Emerging  Technologies  v  Process 
Requirements.  The  technical  change  management 
team  can  provide  a  valuable  service  to  process 
improvement  teams  by  continually  tracking  new 
developments  in  the  technology  world  and  assessing 
their  potential  use  in  enabling  process 
improvements.  It  is  likely  that  the  functional 
elements  engaged  in  process  improvement  have 
neither  the  time,  the  resources,  nor  the  background 
to  do  this.  Some  of  the  emerging  technologies  that 
are  candidates  for  enabling  process  improvement 
include  those  on  the  following  list." 

■  Computer-aided  Design 

■  Groupware 

■  Document  Management 

■  Point-of-Sale  Terminals 

■  LANAVAN  Networks 

■  High  Resolution  Printers 

■  High  Capacity  Storage 

■  Document  Scanners 

■  Smart  Cards 

■  Wireless  Technology 

■  Graphics  Technology 

■  Object  Orientation 

■  Geographic  Systems 

■  Paperless  Manufacturing 

■  Online  Research  Services 


■  Customer  Service  Technology 

■  Client/Server  Technology 

■  Relational  Data  Base 

■  Voice  Recognition 

■  Built-in  FAX  Capability 

■  Pen/Touch  Notebooks 

■  Advanced  Fiber  Optics 

■  Videoconferencing 

■  DataA^ideo  Compression 

■  Virtual  Reality/Simulation 

The  reader  is  also  urged  to  obtain  a  copy  of 
Business  Week’s  special  1994  bonus  issue  entitled: 
“The  Information  Revolution:  How  digital 
technology  is  changing  the  way  we  work  and  live,” 
for  an  informative  presentation  of  emerging 
technologies.  The  article  beginning  on  page  52, 
“The  Enabling  Technologies”  is  especially  relevant 
to  the  present  discussion. 

As  with  much  of  technology,  it  is  not  just  the 
base  technology  that  leads  to  breakthrough  business 
process  performance  but  the  way  different 
technologies  are  combined  in  innovative  ways. 
Many  of  the  base  technologies  listed  above  and 
described  in  the  referenced  article  are  not  very 
exciting  until  they  are  used  together  in  new  and 
different  applications. 

By  not  including  technology  specialists  in 
their  brainstorming  sessions  on  process  innovations, 
process  improvement  teams  run  the  risk  of  missing 
golden  opportunities  to  radically  transform  business 
processes.  Most  often  this  will  happen  through 
ignorance  of  the  meaning  and  potential  application 
of  emerging  technologies  in  various  combinations. 
A  second  possibility  is  that  the  process 
improvement  team  is  not  aware  of  technology  that 
has  been  successfully  used  in  other  areas  of  their 
own  enterprise  and  which  could  easily  and 
inexpensively  be  adapted  to  serve  their  processes. 

7.1.4  Document  Technical  Status.  Once  the 
above  tasks  have  been  completed  in  this  step  of  the 
methodology,  the  technical  change  management 
team  should  prepare  a  status  or  readiness  report. 
This  report  will  note  the  areas  and  issues  of  most 


1  “24  Breakthroughs  That  Are  Changing  the  Way  We  Live  and  Work,”  William  J.  Cook  anbd  Warren  Cohen,  U.S. 

News  and  World  Report,  May  1,  1994. 
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concern  with  respect  to  technological  change  and 
process  improvement.  It  will  highlight  areas  of 
strength  and  weakness  in  the  current  technological 
infrastructure  as  it  pertains  to  on-going  process 
improvement  efforts.  It  will  also  isolate  and 
describe  the  most  promising  new  technologies  that 
may  find  application  in  process  improvement 
efforts.  In  this  way,  it  serves  as  a  heads-up  notice  to 
the  technical  elements  for  demands,  requirements, 
or  requests  that  may  be  forthcoming  from  the 
process  improvement  effort. 

The  report  will  also  be  used  later  in  this  phase 
of  the  methodology  to  develop  an  action-oriented 
plan  to  enhance  existing  technical  enablers,  remove 
technical  obstacles,  and  lower  barriers  to  change 
that  may  emanate  from  the  technical  elements.  The 
report  should  also  be  used  by  the  process 
improvement  team  itself  to  adjust  process  design, 
wherever  possible,  to  take  advantage  of  technical 
strengths  and  avoid  or  minimize  the  impact  of 
existing  technical  weaknesses. 

7.1.5  Review  and  Approve  Status  Report.  The 

status  report  should  be  reviewed  and  approved 
(validated)  by  the  process  improvement  team  and 
technical  managers  who  are  associated  with  the 
process  improvement  effort  or  who  may  be 
impacted  by  process  improvement  developments.  If 
the  report  indicates  a  probable  potential  for 
incorporating  new  or  emerging  technologies  in 
process  redesigns,  it  may  be  appropriate  to  have 
outside  experts  (vendors  or  consultants)  in  these 
technologies  also  review  the  report. 
Misunderstandings  of  the  potential  application  of 
new  technology  should  be  discovered  as  early  in  the 
process  as  possible  to  avoid  serious  and  potentially 
expensive  problems  later  in  the  improvement 
methodology. 


7.2  Step  14:  Identify  Technical  Change 

Requirements 

The  previous  step  in  this  phase  produced  an 
assessment  or  status  report  on  the  current  situation 
in  the  technological  infrastructure  with  respect  to 
process  improvement  efforts,  and  a  study  of 
potential  technology  enablers  to  process 
improvement. 

This  step  will  result  in  a  technological  impact 
statement  that  defines  the  specific  systems  and 
platform  areas  that  have  to  be  addressed  to  support 
the  potential  requirements  of  the  reengineered 
process.  These  requirements  will  be  defined  in  the 
Process  Improvement  Analysis  Report  produced  in 
Step  7,  Conduct  Improvement  Analysis.  The 
technological  impact  statement  produced  in  this  step 
will  also  include  an  analyzed  list  of  technical 
enablers  for  use  by  the  process  improvement  team 
in  Step  8,  Redesign/Reengineer  Process.  The  final 
change  management  plan  will  be  produced  in  the 
next  step  in  this  phase. 

Ultimately,  the  organization  needs  to  have  a 
clear,  consistent  architectural  framework  for 
incorporating  business  process  requirements.  If 
such  a  framework  does  not  exist,  process 
improvement  efforts  will  soon  overwhelm  the 
technical  staff  and  overload  the  technical 
infrastructure.  Even  if  it  does  exist,  it  may  need  to 
be  modernized  to  accommodate  the  rapid  pace  of 
change  that  follows  business  process  reengineering 
efforts.  The  following  material  in  this  introduction 
to  Step  14  is  derived  from  Paradigm  Shift:  The  New 
Promise  of  Information  Technology.^ 


Work  View 


Business  View 


I 


Application  View 

~r~ 


Technology  View 


Figure  7-1.  Architectural  Views 


Information  View 


25  Paradigm  Shift:  The  New  Promise  of  Information  Technology,  Don  Tapscott  and  Art  Gaston,  McGraw-Hill,  1993, 
Chapter  10. 


Technical  Change  Management  -  (Rev.  5.1;  15  JUN  94) 


7-7 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


Tapscott  posits  that  the  architectural 
framework  consists  of  five  components: 

Each  view  incorporates  several  principles 
which  when  taken  together  provide  a  complete 
framework  for  supporting  business  process 
reengineering  efforts.  The  principles  are  as  follows: 

1.  Business  View: 

■  Customer  Focus.  All  architectural 
decisions  will  support  the  delivery 
of  customer-oriented  systems  that 
are  responsive  to  customer 
demands,  adaptable  to  changing 
markets,  promote  high  quality,  and 
are  easy  to  use. 

■  Consistency.  Wherever  we  have 
common  requirements,  we  will 
treat  them  in  a  consistent  way. 

■  Modularity.  We  will  develop 
architectures  based  on  modular 
components  with  standardized 
interfaces  to  support  flexibility  and 
usability. 

■  Openness.  We  will  choose 
components  and  associated 
standards  to  increase  the  possibility 
of  using  industry  standards  with  a 
preference  for  vendor-neutral 
implementations. 

■  Cost  of  Compliance.  Compliance 
with  architectural  standards  may 
incur  higher  up-front  costs  than 
non-compliant  solutions,  but  will 
pay  off  in  the  medium  to  long  term. 

■  Measurement.  Measuring  the  use 
and  performance  of  the 
architectural  components  will  be 
included  as  part  of  the 
requirements. 


2.  Work  view: 

■  Accessibility.  We  will  provide  the 
necessary  accessibility  to 
authorized  users  to  meet  their 
requirements  for  various  functions 
at  different  work  locations. 

■  Information  Capture.  Information 
should  be  captured  in  computer- 
readable  form  as  close  to  the  source 
of  origin  as  possible,  including 
external  sources. 

■  Information  Exchange.  Once 
captured,  information  should  be 
stored  and  exchanged  using 
electronic  means  such  that  manual 
transcription  and  reentry  are 
avoided. 

■  Common  User  Interface.  Wherever 
possible,  the  various  applications 
and  tools  should  present  a  common 
look  and  feel  to  avoid  confusion 
and  reduce  or  eliminate  user 
training. 

3.  Application  View: 

■  Simplicity.  We  will  avoid 
developing  applications  that  are 
overly  complex  by  separating 
functionality  into  basic  and 
operational  modules  and  by 
managing  information  rather  than 
process. 

■  Reusability.  We  will  support  the 
sharing  and  reuse  of  common 
application  modules  or  components 
across  development  projects  and 
use  common  environments  to 
increase  reusability. 

■  Distribution.  We  will  place  the 
applications  (tools)  and  associated 
information  as  close  as  possible  to 
the  point  of  use  to  address  the 
required  level  of  sharing. 
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■  Replication.  Where  distribution 
results  in  replication  of  common 
applications  in  multiple  work 
locations  on  local  technology 
platforms,  we  will  manage  the 
compatibility  of  these  software 
packages  to  maintain  integrity  and 
support  a  common  architecture. 

■  Methodology.  We  will  use  a 
common  development  methodology 
to  manage  the  application  portfolio 
and  development  environment, 
including  the  means  of  providing 
shareable  components. 

4.  Information  View: 

■  Security.  Protection  of 
confidentiality  and  privacy  of 
information  will  be  included  in  all 
architectural  considerations. 

■  Multiform.  We  will  develop 
architectures  and  resulting  systems 
to  manage  information  in  all  its 
forms  (data,  text,  sound,  image,  and 
video). 

■  Data  Definitions.  All  information 
will  be  subject  to  data 
administration  to  ensure  connmon 
definitions  and  provide  for 
consistency  of  use. 

■  Stewardship.  Responsibility  for 
data  integrity  of  various 
information  subjects  will  be 
assigned  to  particular  business 
units,  and  they  will  assume 
obligations  for  making  this 
information  available  to  other 
authorized  users. 

5.  Technology  View: 

■  Diversity.  We  will  use  the  best  type 
of  technology  platforms  for  the 
intended  purpose  while  reducing 
the  diversity  of  different 


technologies  within  a  single  type  of 
platform,  in  preference  to  one 
common  standard  per  platform 
type. 

■  Interchangeability.  We  will  choose 
and  implement  technology 
components  such  that  we  have  the 
option  of  interchanging  vendor 
products  for  functional, 
performance,  or  cost  reasons  with 
no  or  minimal  disruption  to  the 
technology  service. 

■  Workstation  Orientation.  We  will 
utilize  intelligent  multifunctional 
workstations  as  the  exclusive  or 
primary  means  of  delivering 
functionality  to  end  users. 

■  Network  Orientation.  We  will 
attach  all  workstations  directly  to 
the  network,  either  locally  or 
through  wide  area  networks  (wired 
or  wireless)  with  secure 
conununications  linkages  to  all 
required  servers. 

It  should  be  clear  from  studying  the  principles 
above  that  there  is  a  definite  and  critical  relationship 
between  the  elements  of  the  information 
infrastructure  and  the  objectives  of  process 
reengineering.  Architecture  is  the  means  of  aligning 
the  reengineering  with  information  technology  in  a 
way  that  creates  or  preserves  interoperability  which 
is  the  basis  for  evolving  to  the  integrated  enterprise. 
Technical  change  requirements  must  be  filtered 
through  the  lens  of  architecture  if  lasting  progress  is 
to  be  made. 

The  following  tasks  are  performed  in  the 
Identify  Technical  Change  Requirements  step: 

■  Review  Process  Improvement 

Recommendations 

■  Identify  Technology  Best  Practices 

■  Evaluate  Technical  Change 

Requirements 

■  Develop  Time  and  Cost  Estimates 
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■  Perform  Technical  Impact  Statement 

■  Review  and  Approve  Technical  Impact 
Statement 

7.2.1  Review  Process  Improvement 
Recommendations.  At  this  point  in  the 
methodology  (see  Step  7),  the  process  improvement 
team  will  have  identified  multiple  improvement 
opportunities,  many  of  which  will  have  technology 
implications.  The  technology  change  management 
team  reviews  these  recommendations  to  determine 
the  potential  impact  on  the  existing  information 
infrastructure  as  well  as  the  relationship  of  these 
potential  changes  to  the  architectural  principles 
which  should  govern  all  change  management 
actions. 

Each  recommendation  in  the  report  should  be 
classified  according  to  the  severity  of  its  impact  on 
the  existing  technological  infrastructure.  Later  in 
this  step,  this  data  will  be  used  to  construct  the 
technical  impact  statement  (see  7.2.5). 

Suggested  categories  include  the  following 
although  the  actual  classification  scheme  should  be 
worked  out  with  the  technical  elements. 

■  Architectural  Impacts: 

—  Conforms  to  current  approved 
architectures 

—  Requires  variance  to  current 
approved  architecture 
—  Requires  new  architectural 
development 

■  Infrastructure  (operational)  Impacts: 

—  Hardware  platforms 
—  Communications  platforms 
—  Systems  software  implications 
—  Data  base 
—  Application  systems 
—  User  interfaces 

■  Platform  (capacity)  Impacts: 

—  Within  the  capacity  of  existing 
platforms 


—  Requires  upgrades  to  existing 
platforms 

—  Exceeds  existing  and  current 
planned  capacity 
—  Requires  new  platforms 

■  Personnel  Impacts: 

—  Within  skill  base  of  current  staff 
—  Requires  additional  training  for 
current  staff 

—  Requires  access  to  technical 
expertise 

—  Requires  new  staffing 

Classification  of  potential  impacts  on  the 
technological  infrastmcture  is  the  first  step  in 
constructing  a  project  slate  that  will  be  used  to 
guide  activity  in  the  enterprise  engineering  phase  of 
the  methodology.  The  project  slate  cannot  be 
completed  until  after  the  review  and  approval  of  the 
Functional  Economic  Analysis. 

7.2.2  Identify  Technology  Best  Practices.  In  any 

large  organization,  there  should  be  several,  if  not 
many,  examples  of  best  practices  with  respect  to 
technology  utilization.  Often,  a  process 
improvement  team  will  be  unaware  of  what  other 
functional  groups  are  doing.  The  technology 
change  management  team  should  function  as  an 
internal  consulting  group  facilitating  the  exchange 
or  sharing  of  technology  innovations  throughout  the 
organization. 

Examples  of  best  practices  in  technology 
utilization  might  include  any  of  the  following 
categories: 

■  Personal  computer  applications 
developed  by  functional  staff 

■  General  purpose  data  bases 

■  Installed  new  technology  such  as  CD- 
ROM  or  character  recognition 

■  Pilot  or  prototype  systems  based  on 
reengineered  processes 

■  Innovative  training  systems  on 
technology 

■  Centers  of  expertise  on  new  business 
methods 
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Large  business  units  may  give  some  thought  to 
developing  an  internal  best  practices  data  base  and 
providing  access  to  it  throughout  the  unit.  External 
benchmarking  is  also  recommended  for 
investigating  how  other  organizations  assimilated 
new  technologies  and  found  innovative  uses  for 
them.  This  type  of  benchmarking  can  be  performed 
outside  the  confines  of  a  specific  process 
improvement  effort.  Attendance  at  trade  shows, 
membership  in  user  groups,  use  of  on-line  networks 
such  as  Internet  and  CompuServe,  subscriptions  to 
best  practices  data  bases,  and  access  to  a  good 
technical  library  are  other  techniques  that  can  be 
used  to  track  technology  best  practices  on  a 
continuing  basis. 

The  objective  of  the  technical  change 
management  team  should  be  to  become  highly 
proactive  in  consulting  with  process  improvement 
teams  on  the  potential  uses  of  new  and  emerging 
technologies  while  at  the  same  time  maintaining  an 
effective  interface  with  the  organization’s  technical 
elements. 

7.2.3  Evaluate  Technical  Change  Requirements. 

Once  the  above  two  tasks  have  been  completed  for 
a  given  process  improvement  project,  the  technical 
change  management  team  is  ready  to  work  with  the 
technical  elements  to  define  specific  requirements 
and  specifications  for  potential  technology 
betterments  in  support  of  process  improvement 
objectives.  This  consists  of  consolidating  all  the 
information  related  to  proposed  technology  changes 
gathered  from  the  process  improvement  team, 
consultation  with  technical  elements  on  architecture 
and  infrastructure  issues,  and  reviewing  information 
gathered  from  external  sources. 

The  result  should  be  a  short  (2  to  3  page) 
description  of  the  requirements  to  support  each 
change  element.  At  this  stage  in  the  methodology, 
these  should  be  developed  and  maintained  in  draft 
form.  Some  items  will  be  dropped  from  the  list 
after  further  investigation,  and  new  information  will 
be  added  as  it  becomes  available.  As  the  process 
improvement  team  approaches  the  time  to  develop 
the  final  Functional  ^onomic  Analysis  (FEA) 
decision  document,  the  technical  change 
requirements  developed  in  this  task  will  be 
incorporated  into  the  final  technology  change 


management  plan.  At  this  time,  however,  these 
change  requirements  should  be  considered  work  in 
process. 

7.2.4  Develop  Time  and  Cost  Estimates.  Using 
the  results  from  the  previous  task,  the  technical 
change  management  team  can  begin  to  collect  time 
and  cost  estimates  related  to  proposed  technical 
changes  and  innovations.  This  data  will  be  needed 
by  the  process  improvement  team  members  as  they 
develop  their  FEA.  The  process  improvement  team 
will  be  able  to  capture  time  and  cost  estimates  as 
they  relate  to  the  business  process  but,  in  most 
cases,  will  not  be  qualified  to  estimate  the  time  and 
costs  directly  associated  with  technology  decisions. 
By  having  the  technology  change  management  team 
develop  these  estimates,  the  confidence  factor  in  the 
FEA  will  be  that  much  greater. 

7.2.5  Perform  Technical  Impact  Statement.  With 
all  the  above  data  gathered,  the  change  management 
team  is  positioned  to  prepare  the  technical  impact 
statement  (TIS).  This  statement  patterned  after  an 
environmental  impact  statement  required  for 
construction  projects  performs  the  same  service.  It 
describes  the  impacts  on  the  existing  technological 
infrastructure  that  will  occur  if  the  slate  of  technical 
improvements  is  approved  for  implementation.  The 
technical  impact  statement  goes  beyond  simple  time 
and  cost  elements  (although  this  data  is  included) 
and  describes  the  overall  effect  of  the  change  effort. 
The  TIS  focuses  on  non-economic  decision  support 
data  and  indirect  costs  associated  with  technology 
insertion  or  upgrades  to  existing  plant  and 
equipment.  Such  factors  are  usually  not  part  of  the 
FEA  which  is  focused  more  on  the  business  process 
itself  than  the  shared  infrastructure  needed  to 
support  the  reconunended  changes  and 
improvements. 

The  following  areas  may  be  included  in  the 

TIS: 

■  Physical  facilities  including  power 
supplies,  HVAC,  wiring,  and  cables 

■  Systems  architectures,  configurations, 
and  templates 

■  Platforms  including  hardware, 
communications,  and  systems  software 
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■  Peripherals  and  interfaces 

■  New  applications  systems  and  data  base 
support 

—  Specification  and  design 
—  Development  and  testing 
—  Implementation  and  deployment 

■  Legacy  systems  modifications 

■  Migration  systems  integration 

■  Compatibility  and  interoperability 

■  Operations  and  maintenance 

■  Service,  customer  training,  and  customer 
support 

■  Staffing  and  staff  training 

■  Rules  and  regulations 

■  Policy  and  procedures 

■  Administrative  support  systems  and 
services 

■  Supplier  relationships 

■  Procurements 

■  Contracts 

■  Budgets  and  funding 
Capacity  planning 
Measures 

7.2.6  Review  and  Approve  Technical  Impact 
Statement.  The  TIS  is  submitted  to  higher 
authority  for  review,  validation,  and  approval.  Due 
to  the  fact  that  technical  infrastracture  is  a  shared 
resource,  the  TIS  may  include  one  or  more  process 
improvement  projects  that  depend  upon  shared 
resources. 

7.3  Step  15:  Develop  Technical  Change 

Management  Plan 

After  the  technical  impact  statement  has  been 
reviewed  and  the  process  improvement  team  has 
completed  Step  8,  Redesign/Reengineer  Process, 
the  formal  change  management  plan  can  be 
completed.  The  technical  change  management  plan 
will  be  one  of  the  inputs  to  enterprise  engineering 
along  with  the  FEA  and  organizational  change 
management  plan.  It  will  be  the  role  of  the  process 
improvement  team  during  the  enterprise 


engineering  phase  to  integrate  all  three  change 
plans. 

The  formal  plan  for  instituting  technical 
changes  must  include  a  strategy  for  overcoming 
technical  barriers  and  human  resistance  to  change. 
The  plan  should  also  include  a  synopsis  of  likely 
staffing,  training,  and  development  requirements. 

The  following  tasks  are  performed  in  this  step: 

■  Design  High-level  Technical  Models 

■  Identify  Barriers  to  and  Implications  of 
Change 

■  Develop  Strategies  for  Addressing 
Barriers 

■  Identify  Technology-related  Training 
Requirements 

■  Develop  Technology  Change 
Management  Plan 

■  Review  and  Approve  Technology 
Change  Management  Plan 

7.3.1  Design  High-level  Technical  Models.  In 

Paradigm  Shift,  Tapscott  says  the  following  about 
technical  models  or  architectures: 

By  using  a  generic  set  of  requirements  and 
solutions,  it  is  possible  to  develop  a 
conceptual-level  architecture  that  can  be  used 
to  both  foster  understanding  about  the 
enabling  effects  of  IT  and  begin  the 
migration  of  the  technology  infrastructure 
itself. 

Tapscott  goes  on  to  describe  three  elements  that 
m^e  up  the  technology  component  of  the  general 
architecture: 

■  Application  environments.  Application 
environments  are  prepackaged  groupings 
of  procedures  which  have  a  natural 
affinity.  By  thinking  in  terms  of 
application  environments,  it  becomes 
possible  to  set  expectations  for  business 
process  improvement  that  leverages 
investments  in  technology  across  a  broad 
range  of  business  processes  with  high 
degrees  of  interoperability.  Some  of  the 
possible  application  environments 
include  the  following: 
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—  Data  entry 
—  Inquiry  processing 
—  Expert  systems 
. —  Document  processing 
—  Storage  and  retrieval 
—  Image  processing 
—  Video  processing 
—  Electronic  mail 
—  Enhanced  telephony 
—  Videoconferencing 
—  Transaction  processing 
—  Decision  support 
—  Real-time  control 
—  Electronic  publishing 
—  Graphics  processing 
—  Sound  processing 
—  Hypermedia  processing 
—  Voice  mail 

—  Shared-screen  conferencing 
—  Broadcasting 

■  Technology  environments.  Technology 
environments  are  services  required  to 
support  an  application  environment. 
Common  technology  environments 
include  the  following: 

—  User  interface  management 
—  Information  management 
—  Transaction  management 
—  Operating  systems 
—  Communications 


—  Local  switching  networks 
—  Value-added  wide  area  networks 

Technology  change  management  teams 
working  with  systems  architects  and 
engineers  can  work  together  to  develop  standard 
solution  sets  made  up  of  various  combinations  of 
the  elements  in  the  technical  architecture.  These 
solution  sets  can  then  be  offered  as  potential 
technology  enablers  to  process  improvement  teams. 
Because  the  solution  sets  represent  customizable  re¬ 
use  models,  great  economies  of  time  and  cost  can  be 
realized  while  offering  powerful  technology  tools  to 
improvement  teams. 

7.3,2  Identify  Barriers  to  and  Implications  of 
Change.  The  technology  change  management  team 
should  also  work  to  identify  barriers  to  change  or 
more  precisely,  barriers  to  technology  insertion  in 
support  of  process  improvement  objectives. 
Common  barriers  include  the  following. 

■  Legacy  systems  that  still  serve  vital 
functions  and  can  only  be  replaced  at 
great  time  and  cost 

■  Obsolete  technology  including  low- 
powered  personal  computers 

■  Low  capacity  or  non-existent  cabling  to 
support  interconnected  work-group 
computing  local  area  networks 


Technology  platforms.  Technology 
platforms  are  the  facilities  required  to 
support  information  technology 
applications.  Platforms  are  engineered 
around  a  standard  set  of  hardware, 
communications  and  systems  software 
options.  Possible  classes  of  platforms 
include  the  following: 

—  Mainframes 

—  General  and  special  purpose 
minicomputers 

—  Intelligent  workstations 

—  Work-group  servers 

—  Department  servers 

—  External  servers 

—  Local  area  networks 


■  Platforms  mnning  various  types  and 
levels  of  system  software  that  make 
interoperability  problematic 

■  Lack  of  defined  architectures  to  guide 
technology  insertion 

■  Lack  of  technical  support  personnel  or 
skill  deEciencies 

■  High-maintenance  installations  that  have 
little  resource  for  new  development  or 
new  technology  insertion 
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7.3.3  Develop  Strategies  for  Addressing 
Barriers.  Each  barrier  should  be  evaluated  in  terms 
of  specific  process  improvement  opportunities  with 
respect  to  technical  requirements.  The  change 
management  team  must  work  with  the  technical 
elements  to  develop  strategies  for  removing  barriers 
to  process  improvement.  In  those  cases  where 
barriers  cannot  be  eliminated,  alternative  means  of 
satisfying  process  improvement  objectives  must  be 
found. 

It  should  be  noted  that  in  some  cases, 
migration  systems  plans  may  be  in  place  which 
require  the  elimination  of  functional  barriers  to 
change  and  improvement.  The  technology  change 
management  team  may  find  itself  working  in 
reverse  so  to  speak. 

7.3.4  Identify  Technology-related  Training 
Requirements.  Organizations  engaged  in  process 
improvement  and  technical  architecture 
development  should  consider  developing  a  learning 
architecture  designed  with  the  same  care  as  other 
architectures.  The  concept  of  behavior  modification 
discussed  in  Section  12  in  this  guide  is  an  excellent 
technique  for  training  on  technical  matters.  But  for 
this,  or  any  other  technique  such  as  just-in-time 
learning,  or  multimedia-based  learning  to  be  most 
effective,  there  must  be  an  overall  strategy  in  place. 
This  strategy  can  be  effectively  represented  in 
models  and  matrices  that  take  into  account  process 
or  functional  responsibilities  associated  with 
process  improvement  projects. 

However  approached,  training  requirements 
are  co-equal  to  process,  organizational,  and 
technical  requirements  with  respect  to  process 
improvement.  The  training  implications  of  all 
technical  decisions  should  be  considered 
concurrently  with  the  technical  decision. 

7.3.5  Develop  Technology  Change  Management 
Plan.  The  change  management  plan  should  be 
developed  according  to  the  following  outline: 


■  Change  requirement  and  description 

■  Objectives  and  goals  expressed  in 
performance  terms 

■  Action  plan  for  achieving  the  objective 
with  schedules  and  milestones 

■  Resource  allocation  plan  for  supporting 
the  change  process 

■  Communications  plan 

■  Training  plan 

■  Issue  resolution  plan. 

The  change  management  plan  will  be  a 
synthesis  of  all  the  change  elements  developed  in 
tandem  with  the  process  improvement  team.  As  the 
improvement  project  moves  into  the  enterprise 
engineering  phase,  the  change  management  team 
will  monitor  progress  and  make  changes  and 
adjustments  as  necessary. 

7.3.6  Review  and  Approve  Technology  Change 
Management  Plan.  This  plan  like  all  others  is 
forwarded  to  higher  authority  for  review  and 
approval.  Unlike  many  of  the  other  plans  though, 
this  one  will  be  continuously  revised  and  updated  as 
the  process  improvement  project  moves  through  the 
enterprise  engineering  and  project  execution  phases. 
Once  the  plan  is  approved  by  higher  authority,  it 
becomes  part  of  the  input  to  the  enterprise 
engineering  phase. 

Addendum 

The  figure  on  the  following  two  pages 
lists  thirty  principles  or  ways  information 
technology  can  enable  or  influence  process  and/or 
work  reengineering.  Change  management  teams 
may  find  this  a  useful  starting  point  in  their  search 
for  ways  to  spark  creative  thinking  among  process 
improvement  teams.“ 


25  See  Paradigm  Shift,  Pages  213-218. 
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IT-Enabled  Work  Reengineering 

1 

Work  systems  will  have  a  customer  focus.  Internal  tasks  that  do  not  contribute 
to  meeting  cusomter  needs  will  be  minimized. 

2 

In  work  reengineering  programs,  the  focus  will  be  on  improving  and  changing 
the  business  not  just  the  organization. 

3 

Work  activities  and  processes  will  be  performed  in  parallel. 

4 

Whole  jobs  with  attendant  responsibilities  and  commitments  will  be  created. 

5 

The  role  of  management  is  to  support  those  who  are  dealing  directly  with 
customers— the  front  line. 

6 

Individual  contributors  will  be  able  to  play  more  than  one  role. 

7 

All  management  support  information  will  be  captured  as  a  by-product  of  doing 
work  and  not  as  an  additional  set  of  activities. 

8 

Virtual  functions  will  be  created  independent  of  location. 

9 

information  will  be  available  to  answer  customer  inquiries  at  ail  times. 

10 

Processes  will  be  designed  for  flexibility. 

11 

Where  possible,  work  activities  will  be  broadened  to  include  all  tasks  that 
involve  meeting  a  local  or  enterprise  goal. 

12 

Hierarchical  bureaucracy  will  be  eliminated. 

13 

Redundant  activities  will  be  searched  and  destroyed. 

14 

Saved  time  will  be  reinvested  and  tasks  delegated. 

15 

Shadow  functions  (unproductive  activities  such  as  telephone  tag,  waiting  for 
meetings  to  start,  looking  for  things)  will  be  eliminated. 

Figure  7-2(a).  IT-enabled  Work  Reengineering 
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tT-Enabied  Work  Reengineering 

16 

Shadow  records  (unproductive  copying  and  filing)  will  be  minimized. 

17 

Miscommunications  will  be  minimized. 

18 

Media  transformations  will  be  minimized. 

19 

Controlled  access  to  source  information  will  be  provided. 

20 

Information  relays  will  be  reduced. 

21 

Coordination  of  work  processes  will  be  automated. 

22 

Backup  resources  of  people  and  information  will  be  established. 

23 

Any  individual  will  be  able  to  communicate  with  any  other  through 
participation  in  the  corporate  network. 

24 

Systems  required  for  high  performance  work  will  be  available  to  users. 

25 

Jobs  will  be  clearly  defined. 

26 

Focused  job  training  and  knowledge-based  support  will  be  provided 
creating  a  working-learning  environment. 

27 

Compensation  will  be  linked  to  competency  and  to  accomplishment  rather  than 
to  position  in  a  hierarchy. 

28 

There  will  be  no  layoffs. 

29 

The  old  will  not  be  eliminated  until  a  suitable  new  alternative  has  been  forged. 

30 

The  protocols  for  client/server  organizational  structures  will  be  continuously 
defined  and  redefined. 

Figure  7-2(b).  IT-enabled  Work  Reengineering 
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SECTIONS.  PHASES:  ENTERPRISE  ENGINEERING 


It  is  importtint  to  understand  that  at  the 
beginning  of  this  phase  of  the  methodology,  nothing 
of  major  significance  has  happened  in  the  real  world 
of  business  and  functional  operations.  Costs  have 
not  been  reduced,  cycle  time  has  not  been 
decreased,  quality  and  service  have  not  improved. 
What  has  happened  is  that  the  process  improvement 
team  has  identified  a  series  of  process, 
organizational,  and  technical  changes  that  should 
lead  to  quantifiable  improvements  in  overall  process 
performance  if  and  when  this  series  of  changes  is 
implemented. 

In  essence,  the  work  to  this  point  has  resulted 
in  what  may  be  called  an  architectural  rendering  of 
the  intended  new  process.  Work  performed  in  this 
phase  of  the  methodology  is  analogous  to 
developing  blueprints  and  constructing  system 
components.  Work  in  the  next  and  final  phase  is 
concerned  with  installation,  assembly,  and 
deployment  of  the  engineered  process  and 
supporting  systems. 

If  the  new  (TO-BE)  process  designs  require 
other  than  trivial  changes  in  the  information  and 
communications  systems  infrastracture  that 
supports  the  process  under  study,  those  information 
and  communications  systems  must  be  reengineered. 
Since  such  changes  and  improvements  will  always 
impact  people  and  the  way  in  which  they  work 
together,  the  organizational  components  must  also 
be  reengineered  consistent  with  process  and 
technological  improvements.  We  term  this  phase  of 
the  methodology  enterprise  engineering  because 
changes  to  the  technical  and  oiganizational 
infrastructure  in  support  of  (or  to  enable)  new 
process  designs  will  invariably  impact  the  entire 
enterprise. 

Therefore  enterprise  engineering  is  always  a 
cross-functional  endeavor.  Success  requires  the 
active  participation  of  functional  staff,  technical 
staff,  and  human  resource  and  organizational 
specialists.  Ideally,  a  process  owner  has  been 
designated  to  lead  this  cross-functional  effort  to 
ensure  that  the  needs  of  the  enterprise  as  expressed 
in  terms  of 


mission,  goals,  and  objectives  are  foremost  in  the 
minds  of  the  enterprise  engineering  team. 

The  inputs  to  this  phase  consist  primarily  of 
the  following: 

■  Approved  Functional  Economic  Analysis 
(FEA)  case  for  action 

■  Technological  Change  Management  Plan 

■  Organizational  Change  Management 
Plan 

■  TO-BE  Activity  and  Data  Models. 

While  the  inputs  listed  above  will  contain 
specific  requirements  for  enterprise  engineering,  it 
is  helpful  for  the  improvement  team  to  maintain 
focus  on  the  general  objectives  for  process 
reengineering.  Specific  process,  technical  and/or 
organizational  requirements  or  specifications  that 
seem  to  lead  to  changes  that  are  counter-productive 
to  achieving  the  general  objectives  should  be 
questioned  or  challenged.  These  general  objectives 
are: 

■  Develop  a  process  management  concept 
that  focuses  efforts  on  achieving 
superlative  customer  quality  and  service. 

■  Exploit  the  capabilities  of  work-group 
computing  in  support  of  cross-functional 
work  teams. 

■  Streamline  processes  to  remove  or 
reduce  non- value  added  activities,  cycle 
time  and  costs. 

■  Utilize  technology  innovations  that 
leverage  work  team  effectiveness 
through  information  sharing  and  peer-to- 
peer  communications. 

■  Reduce  the  adverse  effects  of  stovepipe 
management  structures  by  delegating 
decision-making  authority  to  the  lowest 
levels  possible  consistent  with 
maintaining  accountability. 
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■  Integrate  computing  environments  across 
the  organization  to  eliminate  or  reduce 
harmful  redundancy  and  excessive 
infrastructure  costs. 

■  Integrate  data,  text,  voice,  and  image 
within  a  program  of  enterprise-wide 
information  resource  management. 

■  Extend  process  management  and  value 
chain  concepts  beyond  organizational 
boundaries  to  establish  effective  supplier 
and  customer  partnerships. 

■  Maximize  utilization  of  electronic 
commerce  throughout  and  beyond  the 
organization. 

Because  individual  process  improvement 
efforts  are  focused  on  a  particular  process, 
subprocess,  or  collection  of  activities,  it  is  entirely 
possible  that  improvements  in  one  process  area  of 
the  enterprise  may  conflict  with  improvements 
planned  for  other  process  areas  to  the  detriment  of 
the  enterprise  as  a  whole.  This  phase  of  the 
methodology  is  concerned  with  maintaining  an 
enterprise  focus  to  ensure  that  all  process 
improvement  projects  contribute  to  enterprise  goals 
and  objectives. 

Therefore,  it  may  be  necessary  to  challenge 
elements  of  an  approved  change  program  if 
implementing  those  elements  would  have 
detrimental  effects  in  other  areas  of  the  enterprise. 
Enterprise  engineering  work  teams  must  develop 
and  maintain  an  enterprise  perspective  while 
engineering  elements  of  a  specific  process 
improvement  project.  The  list  of  global  enterprise 
objectives  above  provide  some  criteria  for 
maintaining  the  necessary  perspective. 

Enterprise  engineering  is  concerned  with 
establishing  technical  platforms  in  support  of 
process  information  and  communications 
requirements.  These  platforms  include  computing 
and  communications  hardware,  systems  software, 
data  structures,  application  systems,  and  end-user 
facilities.  Platforms  may  include  any  combination 
of  mainframe,  minicomputer,  workstations,  and 
personal  computer  configurations.  Enterprise 


engineering  includes  the  activities  of  specification, 
design,  development  (and/or  procurement),  testing 
with  respect  to  all  systems  components.  Specific 
components  may  be  procured  from  commercial 
sources  (Commercial  Off-the-Shelf  [COTS]), 
government  sources  (Government  Oflf-the-Shelf 
[GOTS]),  developed  in-house,  or  developed  under 
contract.  Systems  integration  is  a  major  function  of 
enterprise  engineering. 

Of  particular  concern  in  enterprise  engineering 
is  the  selection  or  development  of  migration 
systems  to  replace  existing  or  legacy  systems  that 
are  ineffective  from  a  functional  perspective  and/or 
are  expensive  to  operate  and  maintain.  In  some 
cases,  migration  systems  designation  and  the 
decommissioning  of  related  legacy  systems  may  be 
accomplished  with  little  or  no  functional 
involvement.  This  is  generally  true  when  legacy 
systems  are  highly  redundant  in  their  features  and 
functions. 

In  most  cases,  however,  the  move  to  migration 
systems  will  necessarily  require  significant 
functional  user  involvement  and  cooperation 
because  of  the  probable  impacts  and  dismptions  on 
functional  processes  and  work  procedures.  It  is  best 
to  combine  the  establishment  of  migration  systems 
with  a  reengineering  project  but  this  is  not  always 
possible  due  to  conflicting  priorities  and  available 
resources. 

In  any  case,  it  is  in  the  enterprise  engineering 
phase  of  the  methodology  that  all  such  issues  are 
dealt  with  and  resolved.  The  extent  that  enterprise- 
wide  models  exist,  technical  architectures  are  in 
place,  and  configuration  management  is  practiced 
will  determine  the  complexity  of  enterprise 
engineering  activities  and  the  probabilities  for 
success  from  an  enterprise  perspective. 

The  enterprise  engineering  phase  of  the 
Framework  methodology  is  supported,  in  part,  with 
the  following  resources: 

■  F/MPI  Management  Briefing  on 
Enterprise  Engineering 

■  F/MPI  Enterprise  Engineering 
Assessment 
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■  F/MPI  Enterprise  Engineering  Tutorial 

■  F/MPI  Enterprise  Engineering 
Evaluation  Worksheet 

■  The  DoD  Enterprise  Model  White  Paper 

■  Corporate  Information  Management  for 
the  21st  Century:  A  DoD  Strategic  Plan. 
Enterprise  Integration:  Implementing 
Strategy 

■  Tactical  Integration  Plan 

■  Migration  Strategy  Template 

■  Rationale  for  Integration  Checklist  for 

Migration  Assessment. 

The  techniques  (see  Section  10)  most  useful  in 
this  phase  include  the  following: 

■  Brainstorming 

■  Nominal  Group  Technique 

■  Activity  Modeling 

■  Data  Modeling 

■  Program  Decision  Process  Chart 

■  Cause  and  Effect  Analysis. 

8.1  Step  16:  Configure  Technical  Platform 

In  the  era  of  stand-alone  (stovepipe)  systems 
and  the  deployment  of  islands  of  technology,  it  was 
not  necessary  to  have  an  enterprise  view  of  the 
technical  platform  consisting  of  the  totality  of 
computer  and  communications  boxes  and  their 
associated  systems  software.  Systems  did  not  “talk” 
to  each  other,  data  was  not  shared  across  systems 
boundaries,  and  the  processes  such  systems 
supported  were  not  integrated  at  the  functional 
level.  Hardware  platforms  were  selected  or 
designed  to  optimize  the  requirements  of  the 
specific  application  or  function  they  were  intended 
to  support.  The  situation  was  further  exacerbated 
by  the  lack  of  interoperability  across  vendor  lines. 
TTiere  were  few  technical  or  industry  standards  in 
place  and  the  standards  that  did  exist  were 
compromised  by  vendors  to  maintain  “account 
control”  by  mal^g  it  difficult  or  impossible  to 
connect  equipment  in  a  multi-vendor  fashion. 


The  conventional  wisdom  in  this  era  was  that 
first  an  organizational  unit  defined  application 
requirements,  then  selected  appropriate  applications 
software  or  custom  built  their  own,  and  finally 
selected  the  hardware  that  would  best  support  the 
intended  application.  Exercising  this  principle 
resulted  in  multiple  redundant  systems  in  an 
organization,  heroic  efforts  to  exchange  data 
between  disparate  systems,  endless  conversions  and 
upgrades,  high  application  maintenance  costs,  and 
severe  impacts  on  systems  users  who  had  to  contend 
with  multiple  interfaces  to  systems.  Furthermore, 
the  nature  of  these  systems  reinforced  functional  or 
stovepipe  organizational  structures  by  making 
information  a  scarce  resource  that  served  to 
maintain  the  power  structure  within  the 
organization.  The  systems  themselves  contributed 
to  the  erection  of  barriers  between  functional  units 
and  inappropriate  inter-organizational  rivalry  to  the 
detriment  of  the  organization’s  customers. 

In  the  present  era,  the  emphasis  is  on 
managing  information  and  communications  as  a 
corporate  resource.  As  such,  the  technical 
infirastracture  must  be  engineered  to  support  the 
enterprise  as  a  whole.  This  means  that  information 
systems  must  (at  the  same  time)  support  both 
process  requirements  and  corporate  requirements. 

It  is  the  task  of  the  enterprise  engineering  team  to 
make  this  happen. 

The  key  words  in  this  era  are  interoperability; 
integrated  voice,  data,  text,  and  images;  shared  data; 
salability  (personal  computers  to  mainframes); 
client/server  architectures;  expert  systems,  and 
intelligent  user  interfaces.  Architecture  and 
configuration  management  is  the  means  of 
achieving  a  technical  platform  that  serves  both 
process  and  corporate  needs.  Functional  managers 
must  be  aware  of  the  need  to  view  the  technical 
platform  as  a  shared  resource  rather  than  a  private 
information  reserve.  Occasionally,  compromises 
will  be  necessary. 

The  rate  of  change  in  the  technological  arena 
is  staggering.  Personal  computers  costing  a  few 
thousand  dollars  have  the  processing  and  storage 
capability  of  computer  systems  that  filled  rooms 
only  a  few  short  years  ago.  It  is  difficult  even  for 
technical  professionals  to  keep  up  with  the  advances 
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being  made  on  a  daily  basis.  Yet  functional 
managers  must  play  a  significant  role  in  technology 
management  both  from  a  process  perspective  and  a 
corporate  perspective.  Functional  managers  can 
best  be  considered  as  customers  of  their  technical 
suppliers  and  should  strive  to  work  in  partnership 
with  the  technical  elements. 

The  DoD  Strategic  Plan  calls  for  the 
implementation  of  a  flexible,  efficient,  world-wide 
computer  and  communications  infrastructure.  The 
objectives  in  the  Strategic  Plan  related  to  this  goal 
include  the  following: 

■  Apply  policies  and  programs  to  guide 
infrastructure  development  and 
modernization  through  standards-based 
architectures 

■  Strengthen  the  management  of 
information  technology  assets  in 
conformance  with  architectural  and 
configuration  management  principles 

■  Ensure  that  the  computing  and 
communications  infrastructure  can 
evolve  to  meet  the  processing  and 
support  requirements  of  DoD 
information  systems 

■  Benchmark  the  infrastructure  against 
best  commercial  practices  and 
performance  measures 

■  Improve  software  practices  through 
software  process  management,  software 
metrics,  software  engineering 
environments,  and  software  reuse 

■  Evaluate  new  technologies  to  identify 
opportunities  for  significant  cost  savings 
or  improvements  in  mission 
effectiveness. 

The  following  tasks  are  performed  in  the 
configure  technical  platform  step: 

■  Review  Approved  FEA  Package  and 
Supporting  Documents 


■  Review  Technical  Change  Management 
Plan 

■  Assess  Current  Status  and  Capabilities 

■  Design  Hardware  Systems  Support 

Requirements 

■  Design  Communications  Support 
Requirements 

■  Design  Network  Support  Requirements 

■  Design  Systems  Software  Requirements 

■  Document  Technical  Platform 
Requirements 

■  Review  and  Approve  Platform 
Requirements. 

8.1.1  Review  Approved  FEA  Package  and 
Supporting  Documents.  Even  in  the  absence  of 
business  process  improvement,  the  technical 
infrastructure  is  subject  to  continuous  improvement 
and  modernization.  This  activity  is  needed  to 
continuously  improve  the  effectiveness  and 
efficiency  of  the  technological  plant.  The  drivers 
for  this  activity  are  primarily  advances  in 
technology  combined  with  the  tendency  of  legacy 
systems  to  become  obsolete  and/or  expensive  to 
maintain  over  time.  Much  of  this  modernization 
can  be  accomplished  with  little  or  no  involvement 
of  functional  elements. 

Assuming  that  continuous  improvement  of  the 
technological  plant  is  taking  place,  a  business 
process  reengineering  (BPR)  project  represents  a 
serious  disruption  from  the  perspective  of  the 
technical  staff.  Major  BPR  projects  will  almost 
always  require  significant  changes  in  the  technical 
platform  to  accommodate  improvements  in 
functional  processes.  The  technical  staff  must  find 
a  way  to  engineer  a  technical  system  that  can  be 
integrated  into  the  existing  technical  platform  which 
itself  is  in  a  continuous  state  of  flux. 

An  approved  Functional  Economic  Analysis 
(FEA)  business  case  is  the  formal  trigger  for 
initiating  design  changes  in  the  technical  platform. 
The  FEA  and  supporting  documentation  provides 
most  of  the  data  needed  by  the  technical  staff  to 
evaluate  change  requirements,  and  begin  the 
process  of  designing  engineering  changes  to  the 
technical  platform  in  order  to  accommodate  the 
functional  or  business  needs  expressed  in  the  FEA. 
The  first  task  in  the  enterprise  engineering  phase 
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then  is  to  hold  a  conference  to  review  the  intents, 
purposes,  and  requirements  expressed  in  the  FEA 
along  with  the  implications  to  the  existing  technical 
platform. 

This  conference  will  include  functional, 
technical,  and  configuration  management  personnel. 
At  the  time  a  particular  FEA  is  approved,  there  may 
be  other  approved  initiatives  underway  with  respect 
to  a  given  technical  platform.  If  so,  a  way  must  be 
found  to  coordinate  the  requirements  of  multiple 
technical  change  programs  and  rationalize  any 
existing  or  potential  conflicts.  At  all  times,  the 
requirements  in  support  of  a  business  process  must 
be  considered  along  with  the  corporate  requirement 
for  integration  and  interoperability.  The  project 
cannot  go  forward  until  all  conferees  agree  on  a 
course  of  action  with  respect  to  the  approved  FEA 
and  other  initiatives  currently  underway  or  planned. 

8.1.2  Review  Technical  Change  Management 
Plan.  While  the  FEA  is  related  to  a  particular 
business  process  improvement  project,  the 
Technical  Change  Management  Plan  is  related  to 
the  information  infrastructure  as  a  whole.  A 
continuously  maintained  technical  change 
management  plan  provides  a  useful  means  of 


rationalizing  the  requirements  of  multiple  FEAs 
with  the  need  to  build  and  maintain  a  corporate 
information  infrastructure.  This  document  can  also 
be  used  to  coordinate  the  requirements  expressed  in 
FEAs  with  the  on-going  continuous  improvement 
program  performed  by  the  technical  staff. 

Therefore,  Technical  Change  Management 
Plan  can  be  viewed  as  an  engineering  change  order 
control  vehicle  to  ensure  that  there  is  an  orderly  and 
rational  plan  of  action  with  respect  to  the  technical 
plant.  Other  key  documents  related  to  this  task 
include: 

■  The  DoD  Enterprise  Model 

■  Standard  technical  architectures 

■  Configuration  management  plans 

■  General  requirements  in  support  of  the 
Corporate  Information  Management 
(CIM)  initiative. 

Together,  these  documents  help  ensure  an  orderly 
transition  to  a  technical  infrastructure  that  supports 
corporate  objectives  and  requirements  as  well  as  the 
information  management  requirements  of  specific 
business  processes.  The  following  diagram  (Figure 
8-1)  illustrates  this  concept. 


Figure  8-1 .  Inputs  to  Enterprise  Engineering 
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As  shown  in  Figure  8-1,  the  DoD  Enterprise 
Model  is  the  reference  document  for  all 
improvement  projects  whether  triggered  by 
functional  or  technical  elements.  The  Technical 
Change  Management  Plan  integrates  all  current 
FEAs  with  each  other  and  with  planned  technical 
improvements  initiated  by  the  technical  elements. 
The  enterprise  engineering  work  team  forms  life 
cycle  improvement  projects  using  the  Technical 
Change  Management  Plan,  standard  architectures 
and  configuration  management  requirements,  and 
the  general  technical  requirements  expressed  in  the 
DoD  8020  document  series  (CIM  initiative). 
Projects  1  through  4  represent  the  slate  of  approved 
projects  within  an  established  development  cycle. 

This  task  is  primarily  concerned  with 
addressing  two  of  the  four  technical  infrastructure 
values  and  risks  associated  with  life  cycle  and  on¬ 
going  technical  improvement  projects.^ 

■  Strategic  Information  Systems  (IS) 
Architecture 

■  Requirements  Definition  Uncertainty. 

Strategic  IS  architecture  evaluates  the  degree 
to  which  all  projects  are  aligned  with  overall 
information  systems  plans  as  expressed  in  the 
documents  shown  in  figure  8-1.  To  overlook  the 
importance  of  rationalizing  all  proposed  projects  in 
accordance  with  standard  architectures  and 
configurations  is  to  perpetuate  a  functional  or 
stovepipe  view  of  the  information  systems  resource. 
With  few  (if  any)  exceptions,  all  projects  should  be 
in  conformance  with  standards. 

Requirements  definition  uncertainty  addresses 
the  reality  that  with  change  comes  uncertainty. 
Planned  technical  improvements  are  essentially 
concerned  with  productivity.  The  business  view  of 
the  process  in  question  does  not  change,  but  the 
means  of  supporting  that  business  process  through 
IS  improvements  does  change.  FEAs  address  the 
situation  where  the  business  process  itself  is 
undergoing  change,  and  the  IS  support  system  must 
change  to  accommodate  new  business  requirements. 


Parker  and  Benson  suggest  six  levels  of  risk 
assessment  associated  with  project  work: 

Level  0:  Requirements  and  specifications 

are  firm  and  approved.  The  impact 
on  technical  areas  is 
straightforward.  There  is  a  high 
probability  of  no  radical  changes  to 
the  technical  infrastructure. 

Level  1:  Requirements  and  specifications 

are  moderately  firm.  The  impact  on 
technical  areas  is  straightforward. 
There  is  a  low  probability  of 
radical  changes  needed  in  the 
technical  infrastructure. 

Level  2:  Requirements  and  specifications 

are  moderately  firm.  The  impact  on 
technical  areas  is  straightforward. 
There  is  a  reasonable  probability  of 
radical  changes  needed  in  the 
technical  infrastructure. 

Level  3:  Requirements  and  specifications 

are  moderately  firm.  The  impact  on 
technical  areas  is  straightforward. 
There  is  a  high  probability  of 
radical  changes  needed  in  the 
technical  infrastructure. 

Level  4:  Requirements  and  specifications 
are  not  firm.  The  impact  on 
technical  areas  is  complex.  There 
is  a  high  probability  of  radical 
changes  needed  in  the  technical 
infrastructure. 

Level  5:  Requirements  and  specifications 
are  unknown.  The  impact  on 
technical  areas  is  complex.  There 
is  a  high  probability  of  radical 
changes  needed  in  the  technical 
infrastructure. 


26  Information  Economics,  Marilyn  M.  Parker  and  Robert  J.  Benson,  Chapter  14. 
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8.1.3  Assess  Current  Status  and  Capabilities. 

Information  systems  agencies  can  be  viewed  as 
production-oriented  departments  concerned  with 
delivering  established  information  products  and 
services  to  business  units.  Every  request  (project) 
for  changes  (improvements,  enhancements,  new 
capabilities)  delivered  to  information  systems 
agencies  has  the  potential  to  disrupt  current 
operations.  According  to  Parker  and  Benson, 
change  requests  impose  two  additional  risks: 

■  Technical  Uncertainty 

■  Risk  to  the  Integrity  of  the  corporate 
Information  Systems  Infrastructure. 

Technical  uncertainty  can  be  expressed  as  the 
impact  the  proposed  changes  will  have  on  the 
existing  capabilities  of  the  IS  function.  These  risks 
can  be  expressed  in  the  form  of  four  questions: 

1.  To  what  degree  will  the  proposed  project 
require  new  skills  on  the  part  of  the 
technical  staff  and  management?  For 
instance,  if  the  requirements  expressed  in 
an  FEA  specify  client/server 
architectures,  are  the  technical  elements 
skilled  and  experienced  in  this 
technology? 

2.  To  what  degree  will  the  proposed  project 
require  new  hardware  and 
communications  platforms  and  what  is 
the  level  of  risk  associated  with  this  new 
technology?  For  instance,  if  the 
requirements  expressed  in  an  FEA 
specify  CD-ROM  equipped 
workstations,  how  will  this  impact 
current  hardware  platforms? 

3.  To  what  degree  will  the  proposed  project 
require  new  systems  software?  for 
instance,  if  the  requirements  expressed  in 
an  FEA  specify  expert  systems 
interfaces,  how  well  can  the  technical 
elements  respond? 

4.  To  what  degree  will  the  proposed  project 
require  new  applications  software?  Can 
this  requirement  be  satisfied  with  off-the- 
shelf  products  or  will  a  development 


project  be  required?  What  is  the 
estimated  degree  of  complexity 
associated  with  this  application 
requirement? 

The  risk  to  the  corporate  information  systems 
infrastructure  addresses  those  issues  related  to  the 
overall  technical  environment.  This  category  of  risk 
(and  cost)  is  associated  with  non-project  investment 
necessary  to  accommodate  one  or  more  proposed 
projects.  Again  Parker  and  Benson  suggest  a  rating 
scale  to  help  in  infrastructure  change  management. 

Level  0:  The  proposed  project  can  use 

existing  services  and  facilities.  No 
investment  in  IS  prerequisite 
facilities  like  database  management 
is  required.  No  up-front  costs  not 
directly  a  part  of  the  project  itself 
are  anticipated. 

Level  1:  The  proposed  project  will  require 
one  major  infrastructure  investment 
such  as  a  new  user  interface.  The 
associated  up-front  infrastracture 
investment  is  relatively  small. 

Level  2:  Small  changes  in  several  elements 
of  the  computer  service  delivery 
system  are  required.  Some  up-front 
investment  is  necessary  to 
accommodate  this  project.  Some 
later  investment  for  subsequent 
integration  of  this  project  into  the 
mainstream  of  the  IS  environment 
will  be  necessary. 

Level  3:  Moderate  changes  in  several 

elements  of  the  computer  service 
delivery  system  are  required.  Some 
up-front  investment  is  necessary  to 
accommodate  this  project.  Some 
later  investment  for  subsequent 
integration  of  this  project  into  the 
mainstream  of  the  IS  environment 
will  be  necessary. 

Level  4:  Moderate  changes  in  several 

elements  of  the  computer  service 
delivery  system  are  required  in 
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multiple  areas  (i.e.  hardware, 
networks,  database  systems). 
Moderate  up-front  investment  in 
staff,  software,  hardware,  and 
management  is  necessary  to 
accommodate  this  project.  This 
investment  is  not  included  in  the 
direct  project  costs,  but  represents 
IS  facilities  investments  to  create 
the  needed  environment  for  the 
project. 

Level  5:  Substantial  changes  in  several 

elements  of  the  computer  service 
delivery  system  are  required  in 
multiple  areas  (i.e.  hardware, 
networks,  database  systems). 
Considerable  up-front  investment 
in  staff,  software,  hardware,  and 
management  is  necessary  to 
accommodate  this  project.  This 
investment  is  not  included  in  the 
direct  project  costs,  but  represents 
IS  facilities  investments  to  create 
the  needed  environment  for  the 
project. 

As  this  task  is  performed,  it  is  likely  that 
adjustments  may  be  necessary  in  one  or  more  of  the 
elements  or  documents  shown  in  figure  8-1.  For 
instance,  when  a  project  is  assessed  with  respect  to 
current  IS  status  and  capabilities,  the  estimated 
degree  of  cost,  risk,  and  complexity  may  require  a 
change  either  to  the  request  itself  (FEA)  or  to  one  or 
more  of  the  standard  controlling  documents  or  plans 
(current  approved  IS  architecture).  The  important 
point  is  that  work  cannot  proceed  beyond  this  task 
with  any  certainty  of  success  until  all  current 
change  requests  are  assessed  with  respect  to  the 
current  technical  situation,  and  all  required 
adjustments  and/or  accommodations  are  reviewed 
and  approved. 

The  end  result  of  performing  tasks  one 
through  three  in  this  step  is  a  prioritized,  time- 
phased,  risk-assessed,  fully  costed  project  slate  that 
has  been  reviewed  and  approved  by  proper 


authority;  and  one  that  can  be  staffed  with  available 
or  planned  resources.  It  can  be  seen  from  this 
discussion  that  an  approved  FEA  does  not 
necessarily  guarantee  project  implementation  within 
the  proposed  timeframe  (or  at  all)  apart  from  a 
thorough  analysis  and  assessment  from  a  corporate 
perspective. 

At  this  point  in  the  framework  methodology 
and  for  the  remaining  steps  in  the  enterprise 
engineering  phase,  the  controlling  document  is  the 
approved  information  systems  project  which  is 
related  to  one  or  more  FEAs  and  technical 
improvement  initiatives  referenced  in  the  Technical 
Change  Management  Plan.  While  project  work 
proceeds,  organizational  and  technical  change 
management  teams  working  with  functional 
elements  assure  coordination  with  functional 
management  and  business  process  improvement 
teams.  When  this  is  done  well,  the  changes  in  the 
business  process  itself  and  the  organizational 
infrastructure  that  supports  the  business  process  will 
be  related  and  coordinated  with  changes  to  the 
underlying  technical  infrastructure. 

This  means  that  while  the  technical  teams  are 
building  new  information  systems  support  for 
reengineered  business  processes,  functional 
leadership  and  staff  are  preparing  for  the  necessary 
changes  in  policy,  procedures,  management, 
staffing,  and  training.  This  is  critical  especially 
when  the  impending  changes  to  the  business 
process  will  be  felt  outside  the  organization  by 
suppliers  and  customers. 

8.1.4  Design  Hardware  Systems  Support 
Requirements.  The  starting  point  for  designing 
hardware  systems  in  support  of  technical  change 
requirements  is  the  established  geo-technical 
architecture  along  with  existing  configurations 
(deployed  technical  assets).  As  the  enterprise 
engineering  team  proceeds  with  this  task,  they  will 
strive  to  accomplish  several  related  objectives^’: 

■  Link  technology  investments  to  strategic 
goals.  If  the  previous  steps  in  the 
framework  methodology  have  been 
successfully  followed,  this  objective 


27  Information  Payoff,  Paul  A.  Strassmann,  Chapter  14. 
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should  easily  be  achieved.  However, 
technology  changes  rapidly,  and  new 
developments  may  suggest  adjustments 
in  the  design  of  hardware  systems  to 
achieve  unanticipated  improvements 
with  respect  to  support  of  corporate  or 
strategic  goals. 

■  Maximize  the  use  of  existing  or  deployed 
assets  unless  there  is  a  compelling 
business  reason  to  procure  new 
hardware.  Compelling  reasons  include 
requirements  expressed  in  FEAs  and  the 
avoidance  of  maintenance  and 
operational  costs  associated  with 
obsolete  technology. 

■  Look  for  ways  to  use  innovative 
technologies  in  support  of  project 
requirements.  For  instance,  the 
requirements  of  a  project  might  be 
satisfied  by  procuring  either  desktop  or 
laptop  personal  computers.  It  may  be 
that  laptops  with  cellular  modems  might 
provide  a  greater  return  on  investment, 
offer  more  flexibility  for  users  (i.e. 
support  distance  learning  techniques), 
and  simplify  maintenance  and  support 
requirements. 

■  Avoid  investing  in  technology  that  limits 
growth.  Look  for  hardware  systems  that 
are  scalable  (easy  to  upgrade),  conform 
to  industry  standards,  support  a  broad 
range  of  systems  and  application 
software  systems,  can  easily  be  linked 
with  wide  area  and  local  network  and 
communications  systems,  employ  user- 
friendly  interfaces,  and  encourage 
creativity  and  innovative  uses. 

As  stated  earlier,  conventional  wisdom 
suggests  that  hardware  decisions  should  follow 
application  decisions.  That  is,  hardware  systems 
are  subservient  to  application  decisions.  This 
thinking  was  appropriate  in  the  age  of  functionally 
developed  (stovepipe  systems)  before  the  concept  of 
a  technical  infrastructure  in  support  of  corporate¬ 
wide  objectives  was  fully  developed. 


In  the  present  era,  it  makes  more  economic 
and  business  sense  to  develop  a  corporate-wide 
platform  that  emphasizes  interoperability  and  data 
sharing.  This  necessarily  makes  application 
decisions  subservient  to  hardware  and  systems 
software  decisions.  Fortunately,  the  rapid  progress 
in  standards,  off-the-shelf  applications,  and  multi¬ 
vendor  hardware  environments  makes  this  a  non¬ 
issue  from  the  technical  perspective,  but  not  always 
from  the  political  perspective. 

Therefore,  enterprise  engineering  teams  must 
design  the  hardware  platform  to  accommodate  both 
the  corporate-wide  mission  and  the  business  process 
mission  simultaneously;  while  technical  and 
functional  leadership  work  together  to  overcome  the 
political  challenges.  Assuming  technical 
architectures  and  effective  configuration 
management  are  in  place,  hardware  decisions  are 
restricted  to  the  following  questions: 

■  What  computer  platforms  are 
authorized? 

■  Which  one(s)  is  most  appropriate  for  our 
needs? 

■  How  many  units  do  we  need  over  and 
above  existing  inventory? 

■  What  are  the  required  capacity  and 
performance  requirements? 

■  What  features  and  functions  do  we  need? 

■  Where  should  the  units  be  located 
(deployed)? 

■  How  will  we  service  and  support  these 
units? 

8.1.5  Design  Communications  Support 
Requirements.  There  is  no  question  that 
communications  in  all  of  its  forms:  person-to- 
person,  person-to-machine,  and  machine-to- 
machine  is  the  most  important  and  perhaps  least 
understood  facility  within  the  information 
infrastructure.  All  systems  modernization  efforts 
whether  initiated  as  a  business  improvement  project 
or  a  technical  improvement  project  must  give 
considerable  weight  to  the  problems  and 
opportunities  associated  with  effective 
communications.  With  the  advent  of  Integrated 
Systems  Digital  Network  (ISDN)  techniques  and 
the  concept  of  the  Information  Highway, 
communications  capability  is  one  of  the  (if  not  the) 
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paramount  consideration  in  enterprise  engineering 
work. 

There  is  a  de-facto  requirement  for  data 
sharing  and  interoperability  throughout  the 
enterprise  whether  expressed  or  implied  in  all  FEAs 
and  other  requirements  documents.  Enterprise 
engineering  teams  must  ensure  that  all  improvement 
projects  make  optimum  use  of  available  (upgradable 
to  impending)  communications  technology  in 
support  of  specified  and  potential  communications 
requirements. 

Along  with  technical  architectures  and 
configurations  developed  by  the  enterprise  itself, 
international  (dejure)  standards  such  as  the  Open 
Systems  Interconnect  (OSI)  model  provide  the 
context  for  developing  communications  capabilities 
in  support  of  project  requirements.  The  OSI  model 
provides  a  layered  series  of  protocols  needed  to 
establish  effective  communications  support  across 
all  hardware  vendor  equipment  lines.  The  highest 
layer  in  the  model  provides  for  a  wide  range  of  end- 
use  applications  such  as  message  transfer,  file 
transfer,  e-mail,  document  management,  and  a  host 
of  others.  In  the  not-too-distant  future,  we  cannot 
expect  the  OSI  model  to  accommodate  all  forms  of 
data  interchange  (text,  voice,  data,  and  image),  all 
media  (copper,  cable,  fibre  optic,  satellite, 
microwave,  infrared),  embedded  language 
translation  (i.e.  French  to  English),  most  office 
automation  services,  and  other  features  in  the 
evolving  information  highway  metaphor. 

As  with  hardware  components,  the 
conununications  element  of  the  technical 
infrastructure  is  a  corporate  asset  and,  with  few 
exceptions,  the  needs  of  the  enterprise  take 
precedent  over  conflicting  process-related 
requirements  and  specifications. 

8.1.6  Design  Network  Support  Requirements.  In 

this  document,  network  support  is  restricted  to 
apply  to  workgroups  and  functional  or  cross- 
functional  teams  as  in  Local  Area  Network  (LAN). 

In  other  words,  network  support  is  provided  to 
workgroups  within  the  context  of  the  established 
technical  infrastrucmre  which  includes  all 
communications  capability. 


Business  process  improvement  or 
reengineering  invariably  involves  the  concept  of 
empowerment  as  it  applies  to  employee  focus.  For 
employees  to  be  empowered  to  support  internal  and 
external  customer  relationships  and  effectively 
participate  in  supplier  partnerships,  a  teamwork  or 
workgroup  environment  is  usually  called  for. 
Workgroup  members  must  be  able  to  communicate 
with  each  other  (e-mail),  exchange  files  and 
documents,  input  and  access  data  needed  to  serve 
customer  requests  and  service  requirements,  route 
work  tasks  to  available  staff,  share  work  tasks  such 
as  report  preparation,  and  jointly  participate  in 
functional  application  processing  (client/server 
modalities).  Workgroups  supported  with  effective 
local  area  networks  and  client/server  applications 
exhibit  flexibility,  innovation  in  response  to 
customer  situations,  entrepreneurship  (taking 
responsibility),  and  responsiveness  (taking  action). 

The  enterprise  engineering  team  must  use  its 
technical  expertise  to  find  innovative  methods  for 
applying  network  support  for  workgroups.  Often,  a 
functionally-driven  process  improvement  team  will 
not  have  the  knowledge  or  experience  to  design 
process  improvements  that  will  take  full  advantage 
of  network  capabilities.  At  the  same  time,  the 
enterprise  engineering  team  must  ensure  that 
network  solutions  in  support  of  business  process 
requirements  are  fully  compatible  with  the 
corporate  technical  infrastructure  to  maximize  the 
possibilities  for  continued  enhancement  and 
integration  with  other  business  functions.  As  with 
communications  in  general,  network  support  must 
be  constructed  following  corporate  and  industry 
standards  making  full  use  of  commercial  and 
government  off-the-shelf  capability. 

Specific  network  values  include: 

■  Features  and  functions  with  respect  to 
application  requirements 

■  Performance  with  respect  to  installed  or 
planned  hardware  components 

■  Availability  including  service,  training, 
and  support 

■  Cost  both  in  terms  of  the  network 
products  and  infrastructure 

■  Ease  of  operation  with  respect  to  typical 
user  characteristics 
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■  Ease  of  management  both  functionally 
and  technically. 

8.1.7  Design  Systems  Software  Requirements. 
Systems  software  exists  to  control  computer  and 
communications  hardware  components  and 
systems.  It  provides  the  interface  from  user 
applications  to  the  features  and  functions  of  the 
hardware  platform. 

Systems  software  includes  the  following 
types.  Please  note  that  the  meaning  of  the  acronyms 
listed  is  immaterial  to  this  discussion. 

■  Computer  operating  systems  such  as 
DOS,  UNIX,  and  MVS 

■  Communications  control  programs  such 
as  TCP/IP  and  SNA 

■  End  user  or  4th  generation  languages 
such  as  FOCUS  and  SAS 

■  Programming  languages  such  as  COBOL 
and  Ada 

■  Utilities  such  as  file,  document,  and 
protocol  converters. 

Choices  in  systems  software  selection  and/or 
specification  are  determined  by  standard 
architectures.  Indeed,  one  of  the  primary  purposes 
of  architecture  is  to  ensure  that  machines  work 
together,  provide  for  shared  resources,  and  support 
all  current  and  anticipated  application  requirements. 
Enterprise  engineering  teams  must  resist  pressures 
to  acquire  non-conforming  systems  software  solely 
to  support  the  requests  of  a  single  user,  function,  or 
business  process. 

Non-standard  systems  software  is  often 
associated  with  specialized  commercial  application 
software  systems.  In  other  words,  to  use  the 
application,  the  organization  must  introduce  a 
foreign  or  non-standard  systems  software 
component  into  the  technical  infrastructure.  It  is 
impossible  to  overestimate  the  future  problems  and 
their  inherent  associated  costs  associated  with 
violating  architectural  standards.  One  of  the 
primary  problems  may  well  be  loss  of 
interoperability  and  difficulties  in  sharing  data. 


If  the  application  software  in  question  is 
important  and  exclusive  enough  to  warrant  violating 
architectural  standards,  then  it  is  imperative  that  the 
architectural  standards  be  changed  or  modified  prior 
to  introducing  the  requested  application  and  systems 
software  into  the  technical  infrastructure. 

Given  this  discussion,  it  is  the  duty  of  the 
enterprise  engineering  team  to  make  appropriate 
systems  software  design  decisions  in  support  of 
functional  requirements  based  on  established 
architectural  standards. 

8.1.8  Document  Technical  Platform 
Requirements.  At  this  point  in  the  methodology, 
the  enterprise  engineering  team  has  analyzed  all 
approved  functional  and  technical  requirements  for 
information  systems  support,  evaluated  established 
architectural  standards  and  models  with  respect  to 
these  requirements,  assessed  the  current  geo¬ 
technical  architecture  and  configuration  mappings, 
and  designed  the  appropriate  technical  platform  to 
accommodate  both  corporate  and  business  process 
requirements  and  specifications. 

It  is  now  necessary  to  document  the 
recommended  platform  design  changes,  additions, 
and  modifications  into  a  technical  business  case  that 
supplies  appropriate  decision  making  criteria  to 
technical  review  boards  such  as  the  Configuration 
Control  Board.  As  noted  above,  the  requirements 
specified  or  recommended  in  this  document  will  be 
in  support  of  an  infrastructure  project  which  will 
support  one  or  more  approved  FEA  or  technical 
improvement  initiatives.  In  practice,  the  results  of 
this  step  will  be  combined  with  the  outputs  of  the 
next  two  steps  in  order  to  provide  a  complete 
package  of  technical  specifications  including 
platform,  application,  and  database  elements. 

In  most  cases,  the  required  document  will  be 
called  a  Tactical  Integration  Plan  reflecting  the 
importance  of  maintaining  the  integrity  of  the 
technical  infrastructure  as  new  technical  capability 
is  developed  in  support  of  business  process 
improvements.  The  Tactical  Integration  Plan  is 
prepared  under  the  direction  of  a  Technical 
Integration  Manager  and  will  be  fully  described  in 
step  20  in  this  document. 
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8.1.9  Review  and  Approve  Platform 
Requirements.  The  Technical  Platform 
Requirements  Plan  or  Technical  Integration  Plan  is 
intended  for  the  review  of  designated  audiences 
which  may  include  any  of  the  following; 

■  OSD  Principal  Staff  Assistants 

■  Functional  Activity  Program  Managers 

■  Cross-Integration  Assessment  Council 

■  Configuration  Control  Board 

■  Functional  Information  Managers 

■  Other  designated  agencies  and  review 
boards. 

Following  review  and  approval  of  this  plan 
and  the  components  described  in  the  next  two  steps 
of  the  methodology,  the  project  may  proceed  to 
steps  19  and  20  which  result  respectively  in  an 
implementation  plan  and  a  migration  and 
integration  plan. 

8.2  Step  17:  Develop  Application  Systems 

The  technology  infrastructure  exists  to  support 
applications  that  serve  or  advance  corporate 
interests  as  expressed  by  the  oiganization’s  mission, 
goals,  and  objectives.  Each  application  has  a 
purpose  that  justifies  its  existence.  That  purpose 
must  result  in  a  benefit/cost  ratio  greater  than  1.0. 
That  means  that  the  life  cycle  costs  to  specify, 
design,  build,  operate,  and  maintain  the  application 
(including  that  application’s  pro-rata  share  of 
infrastructure  costs)  must  be  less  than  the  value  of 
the  benefits  returned  to  the  enterprise.  In  other 
words,  each  application  in  the  enterprise’s  portfolio 
of  applications  is  (or  should  be)  justified  by  good 
business  management  principles  including  return  on 
investment  (ROI)  calculations. 

While  this  is  a  simple  concept,  the  problem  is 
one  of  accurately  estimating  life  cycle  costs,  and 
then  ensuring  that  the  application  project  is  within 
budget  through  all  phases  in  its  life  cycle.  Risk  and 
uncertainty  (as  well  as  poor  project  management 
and  performance)  are  the  factors  that  contribute 
most  to  project  failures.  The  degree  of  risk  and 
uncertainty  depends  in  part  on  the  class  of 


application  system  required.  There  are  three 
principal  classes  of  application  systems; 

■  Transaction  Processing  Systems  (TPS) 

■  Process  Control  Systems  (PCS) 

■  Decision  Support  Systems  (DSS). 

Transaction  (TPS)  systems  have  the  highest 
risk  associated  with  them.  This  is  because  the 
objective  of  a  TPS  is  to  maximize  automation  and 
minimize  or  eliminate  human  involvement  in  a 
relatively  uncontrolled  human  environment.  This 
means  that  a  TPS  must  enforce  an  organization’s 
policies,  procedures,  and  business  process 
requirements,  with  respect  to  the  application,  in 
their  entirety,  recognize  and  respond  to  every 
conceivable  error  condition,  and  be  easily  and 
quickly  modified  when  the  business  process  is 
changed.  Purchasing  is  an  example  of  a  TPS. 
Electronic  Data  Interchange  (EDI)  can  fully 
automate  this  process. 

Process  control  (PCS)  systems  have  the  next 
highest  risk  associated  with  them.  The  lowered  risk 
is  due  to  operating  in  a  more  stable  environment 
and  being  subject  to  continuous  monitoring.  While 
process  control  has  generally  been  associated  with 
material  handling,  manufacturing,  and  assembly,  it 
is  increasingly  being  applied  to  service-based  or 
office  processes.  Work-flow  management  is  an 
example  of  this  trend. 

Decision  support  (DSS)  systems  entail  the 
least  risk  and  uncertainty  because  they  are  designed 
to  operate  under  human  control  and  are  generally 
less  proceduralized.  DSS  are  often  available  as  off- 
the-shelf  commercial  products  while  the  other  two 
types  of  systems  are  usually  custom  developed. 

Parker  and  Benson  suggest  the  following  risk 
levels  with  respect  to  providing  application  systems 
in  support  of  business  process  needs; 

Level  0;  Programs  exist  with  minimal 
modifications  required. 

Level  1;  Programs  are  available 

commercially  with  minimal 
modifications,  or  programs 
available  in-house  with  moderate 
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modifications,  or  software  will  be 
developed  in-house  with  minimal 
complexity. 

Level  2:  Programs  are  available 

commercially  with  moderate 
modifications,  or  programs 
available  in-house  require  extensive 
modifications,  or  software  will  be 
developed  in-house  with  minimal 
design  complexity  but  moderate 
programming  complexity. 

Level  3:  Software  is  available  commercially 
but  the  complexity  is  high,  or 
software  will  be  developed  in- 
house  and  the  difficulty  is 
moderate. 

Level  4:  No  package  or  current  in-house 
software  exists.  Complex  design 
and  programming  are  required, 
with  moderate  difficulty. 

Level  5:  No  package  or  current  in-house 
software  exists.  Complex  design 
and  programming  are  required, 
even  if  contracted  outside. 

It  should  be  obvious  that  as  the  level  of  risk 
and  uncertainty  increases,  the  potential  benefits  of 
having  the  application  program  should  be 
correspondingly  higher  to  justify  the  added  risk. 

Tapscott  and  Caston“  offer  several  application 
development  principles  that  can  lower  risk  and 
increase  potential  benefits: 

■  Simplicity.  We  will  avoid  developing 
applications  that  are  overly  complex  by 
separating  functionality  into  basic  and 
optional  modules  and  by  managing 
information  rather  than  process. 


■  Reusability.  We  will  support  the  sharing 
and  reuse  of  common  application 
modules  or  components  across 
development  projects  and  use  common 
environments  to  increase  reusability. 

■  Distribution.  We  will  place  the 
applications  (tools)  and  associated 
information  as  close  as  possible  to  the 
point  of  use  to  address  the  required  level 
of  sharing. 

■  Replication.  Where  distribution  results 
in  replication  of  common  applications  in 
multiple  work  locations  on  local 
technology  platforms,  we  will  manage 
the  compatibility  of  these  software 
packages  to  maintain  integrity  and 
support  a  common  architecture. 

■  Methodology.  We  will  use  a  common 
development  methodology  to  manage  the 
application  portfolio  and  development 
environment,  including  the  means  of 
providing  shareable  components. 

By  comparing  these  principles  with  the  risk 
levels  described  above,  it  can  be  seen  that  the  effect 
of  following  the  principles  is  to  reduce  the  level  of 
risk  associated  with  providing  application  programs 
and  systems. 

This  step  of  the  methodology  is  performed  in 
parallel  with  the  previous  step  and  the  next  step. 
This  is  because  of  the  relationships  among 
platforms,  applications  and  data.  This  especially 
applies  to  the  first  three  tasks  in  each  of  these  steps. 

The  following  tasks  are  performed  in  the 
develop  application  systems  step: 

■  Review  Approved  FEA  and  Supporting 
Documentation 

■  Review  Technical  Change  Management 
Plan 

■  Assess  Current  Capabilities 


28  Paradigm  Shift,  Don  Tapscott  and  Art  Caston,  page  245. 
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■  Design  Application  Support  Systems 

■  Develop  Application  Support  Systems 

■  Unit-test  Application  Support  Systems 
with  Data  Base 

■  Document  Application  Support  Systems 

■  Review  and  Approve  Application 
Systems 

8.2.1  Review  Approved  FEA  and  Supporting 
Documentation.  Application  software  exists  to 
serve  the  needs  of  business  processes.  The  needs  of 
business  processes  are  specified  in  a  Functional 
Economic  Analysis  (FEA)  and  supporting 
documents.  A  folly  developed  TO-BE  activity 
model  provides  the  basis  for  developing  application 
program  specifications  and  designs.  Therefore  the 
starting  point  for  all  application  development  is  a 
review  of  the  FEA  package. 

The  FEA  package  also  provides  a  vehicle  for 
supporting  effective  communications  between 
functional  and  technical  personnel.  It  provides  a 
means  of  assuring  that  application  development 
activities  are  linked  to  business  and  process 
objectives,  and  a  means  of  establishing  measures  to 
monitor  progress.  Finally,  the  FEA  package  is  the 
basis  for  developing  prototypes  that  can  be  used  by 
functional  staff  in  specification,  design,  and 
development  and  testing  activities. 

8.2.2  Review  Technical  Change  Management 
Plan.  The  FEA  package,  case  for  action,  or 
business  case  is  specific  to  a  single  business  process 
improvement  initiative.  In  a  functional  (stovepipe) 
application  environment,  the  FEA  would  suffice  as 
guidance  for  technical  personnel  to  begin  systems 
development.  In  a  cross-functional  environment 
striving  to  develop  an  enterprise-wide  technical 
infrastructure  emphasizing  interoperability  and  data 
sharing,  there  must  be  a  coordinating  vehicle  to 
ensure  that  all  application  development  supports 
enterprise  objectives.  This  coordinating  vehicle  is 
the  Technical  Change  Management  plan. 

The  change  plan  (see  figure  8-1)  provides  a 
means  of  coordinating  application  development 
across  functional  units.  The  change  plan  will 
include  or  reference  the  application  architecture 
which  portrays  the  portfolio  of  enterprise 
applications.  (The  application  architecture  is 


developed  as  part  of  business  systems  planning  as 
described  in  Phase  1  of  the  framework 
methodology.) 

Based  on  a  review  of  the  plan,  functional  and 
technical  people  working  together  can  agree  on 
reasonable  compromises  in  application  development 
which  can  benefit  the  enterprise  as  a  whole.  The 
plan  can  also  suggest  areas  where  software  reuse  or 
module  (object)  sharing  is  appropriate. 

8.2.3  Assess  Current  Capabilities.  Unfortunately, 
most  large  organizations  have  done  a  poor  job  of 
maintaining  control  over  their  inventory  of 
application  modules,  programs,  and  systems. 
Furthermore,  application  maintenance  and 
enhancement  activity  over  time  corrupts  software 
(and/or  software  documentation)  and  reduces  the 
opportunity  for  reuse.  Industry  authorities  agree 
that  less  than  20%  of  information  systems  budgets 
are  expended  on  new  development,  and  some 
organizations  spend  virtually  100%  of  their  budgets 
on  maintenance  activities. 

Where  the  principles  of  application  portfolio 
management  described  above  are  followed,  the 
application  portfolio  represents  a  tremendous  asset 
to  support  application  development  by  increasing 
software  sharing  and  reuse. 

The  emphasis  on  sharing  and  reuse  can 
provide  a  stimulus  for  the  information  management 
agencies  to  improve  application  portfolio 
management. 

Available  or  procurable  application  software 
assets  should  be  used  to  the  fullest  extent  possible 
to  lower  the  risks,  costs,  and  response  time  factors 
of  providing  needed  application  support.  This  may 
mean  that  functional  elements  may  need  to  make 
compromises  in  their  business  processes  or 
procedures  that  conflict  in  minor  ways  with 
software  features  and  capabilities.  This  is 
especially  true  in  the  case  of  commercial 
application  packages.  Assessing  current  capabilities 
with  respect  to  new  application  requirements  is 
therefore  a  critical  and  rewarding  task. 
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8.2.4  Design  Application  Support  Systems. 

Modem  application  program  and  systems  design 
calls  for  active  participation  of  functional  personnel 
in  the  design  process.  This  participation  is  usually 
in  the  form  of  rapid  prototyping.  Prototyping 
answers  the  end  user’s  legendary  lament  about 
application  systems  design:  “I  don’t  know  what  I 
want  but  I’ll  know  it  when  I  see  it.”  Rapid 
prototyping  uses  various  combinations  of  the 
following  tools: 

■  Screen  painters  that  allow  users  to 
develop  their  own  interfaces  and 
preferred  method  of  entering  and 
viewing  data  and  information. 

■  Report  generators  that  allow  users  to 
specify  what  data  they  want  from  the 
system  and  how  they  want  that  data 
displayed. 

■  Menu  builders  that  allow  users  to 
develop  the  features  and  functions  they 
want  in  their  system,  and  their  preferred 
means  of  navigating  within  the  system. 

■  Fourth-generation  (4GL)  languages  that 
allow  users  to  develop  the  procedures 
and  algorithms  they  want  in  the  new 
system.  In  conjunction  with  sufficient 
data  base  support,  4GLs  are  so  powerful 
that  in  some  cases  the  prototype  is 
sufficient  to  support  process  needs  and 
no  formal  system  need  be  developed. 

■  Executable  specification  languages  that 
have  the  capability  to  generate  software 
instmctions  that  make  up  significant 
components  of  the  final  system.  In  some 
cases,  code  generation  along  with 
software  reuse  can  substitute  for  formal 
application  system  development. 

Prototyping  recognizes  that  application 
software  development  is  essentially  an  interactive 
process  requiring  the  business  process  knowledge  of 
the  functional  user  and  the  technical  expertise  of  the 
system  builder.  With  prototyping,  neither  party  has 
to  make  assumptions  in  the  other  party’s  area  of 
responsibility.  As  Kenmore  S.  Brathwaite  says  in 


Information  Engineering  Concepts:  “One 
demonstration  is  worth  two  volumes  of 
specifications.”  Once  a  prototype  is  evaluated, 
there  are  five  possible  courses  of  action.  The 
prototype  can: 

■  Be  refined,  retested,  and  reevaluated 

■  Be  used  to  drive  formal  requirements 
analysis 

■  Be  used  as  a  model  for  conceptual 
systems  design 

■  Serve  as  input  to  detailed  design 

■  Serve  as  design  input  to  formal 
application  software  development. 

If  the  development  organization  is  committed 
to  object-oriented  information  systems  and  has 
established  a  useful  library  of  models,  prototypes 
developed  using  object  orientation  methods  can 
usually  be  extended  into  working  systems  even  in 
the  case  of  complex  transaction  processing  systems. 

4GLs  can  be  used  throughout  the 
specification,  design,  prototyping,  and  development 
stages  of  a  project,  and  there  is  a  wide  variety  of 
4GLs  available.  Some  are  more  suited  for 
prototyping  activities  while  some  can  substitute  for 
or  enhance  the  capabilities  of  delivered  decision 
support  systems. 

Application  design  also  includes  the  concept 
of  evaluating  off-the-shelf  commercial  or 
government  systems  as  a  replacement  for  in-house 
or  contracted  systems  development.  During  the 
evaluation  period,  the  design  team  tries  to  find 
application  systems  that  come  closest  to  meeting  the 
requirements  set  forth  in  the  FEA  within  the  context 
of  the  Technical  Change  Management  Plan.  If 
candidate  systems  are  found,  the  team  assesses 
whether  changes  to  the  software  or  changes  within 
the  business  process  itself  must  be  made  in  order  to 
use  the  candidate  system.  This  is  another  reason 
that  it  is  important  for  functional  users  to  participate 
in  the  design  task. 

Computer-aided  Software  Engineering 
(CASE)  tools  are  available  which  automate  the 
systems  design  process.  Such  tools  generally  work 
off  a  repository  system  and/or  automated  dictionary/ 
directory  system  that  contains  design  rules,  business 
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process  activity  models,  data  administration,  and 
data  structure  information.  Some  case  tools  can  be 
used  to  develop  working  prototypes. 

8.2.5  Develop  Application  Support  Systems. 

Once  the  design  team  comprised  of  functional  and 
technical  personnel  are  satisfied  that  the  prototype 
captures  the  essence  of  the  required  application 
system,  development  (or  construction)  can  proceed. 
Note  that  in  the  absence  of  a  prototype,  the  design 
team  would  have  developed  detailed  design 
specifications  for  the  desired  system.  It  should  be 
noted  that  the  risk  and  uncertainty  levels  are  higher 
for  this  method  of  design. 

Development  can  consist  of  any  one  or  a 
combination  of  the  following  development 
techniques: 

■  Write  application  code  using  a 
procedural  programming  language  such 
as  Ada,  COBOL,  or  Basic. 

■  Write  application  code  using  a 
sophisticated  4GL  (non-procedural) 
language  such  as  FOCUS,  SAS,  or  even 
spreadsheet  macros. 

■  Use  object  technology  to  develop 
reusable  software  building  blocks  that 
can  be  assembled  into  finished 
application  systems.  Note  that  non 
object-oriented  coding  techniques  can  be 
used  to  develop  reuse  modules,  but  the 
success  rate  to  date  has  been 
disappointing. 

■  Contract  (out- source)  application 
development  to  a  systems  house. 

■  Purchase  commercial  off-the-shelf 
(COTS)  packages  and  modify  as 
required. 

■  Purchase  COTS  packages  and  adapt  the 
business  process  so  that  it  can  use  the 
software  package  as  is. 


■  Locate  and  acquire  government  off-the- 
shelf  (GOTS)  packages  and  modify  as 
required. 

■  Locate  and  acquire  GOTS  packages  and 
adapt  the  business  process  so  that  it  can 
use  the  software  package  as  is. 

Please  note  that  the  options  listed  above  are 
presented  in  reverse  order  of  preference  with 
respect  to  risk,  cost,  and  response  time  for  delivery 
of  the  finished  system.  One  critical  decision  point 
related  to  all  application  development  is  after 
installation  service,  maintenance,  and  support.  This 
question  should  be  considered  at  the  time  the 
development  option  is  being  selected.  Whomever 
writes  or  modifies  software  code  becomes 
responsible  for  its  maintenance  throughout  its  life 
cycle!  In  general,  the  less  code  written  in  any 
organization,  the  better.  It’s  interesting  to  note  that 
DoD  spends  $42  Billion  for  software  acquisition.^® 

8.2.6  Unit-test  Application  Support  Systems  with 
Data  Base.  Application  systems  are  developed  in 
sections  or  modules  corresponding  to  major  features 
and  functions  in  the  business  process.  It  is  also 
necessary  to  develop  so-called  housekeeping 
routines  that  take  care  of  internal  programming, 
utility,  and  user  interface  functions.  These  modules 
and  routines  are  developed  in  a  sequence  that  aids 
the  unit  testing  effort. 

A  unit  test  is  a  test  of  a  program  module  or 
routine.  As  each  module  or  routine  is  developed,  it 
is  tested  against  mechanical,  logic,  performance,  fit, 
and  finish  criteria.  To  test  a  module,  it  must  have 
access  to  test  data  residing  in  a  real  or  simulated 
data  base  and/or  file  system.  As  each  module 
passes  its  tests,  it  is  shelved  until  enough  modules 
are  completed  to  form  a  subsystem.  As  subsystems 
are  completed  and  tested,  system  tests  are 
conducted.  Subsystem  and  system  tests  are 
described  later  in  the  methodology. 

Functional  users  and  members  of  the  process 
improvement  team  must  participate  in  the  unit 
testing  process.  While  technical  personnel  can 
discern  and  correct  mechanical,  logic,  and 
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performance  errors  and  discrepancies;  only 
functional  users  can  adequately  judge  the  fit  and 
finish  (usability)  features  of  the  application  system. 
The  earlier  in  the  develop  and  test  cycle  such 
discrepancies  are  located,  the  less  risk  to  a 
successful  development  effort. 

The  design  prototype  can  also  be  used  during 
unit  testing  to  aid  in  detecting  omissions  in  module 
functionality.  Such  omissions  will  not  always  be 
evident  in  unit  testing.  It  is  difficult  to  find  a 
problem  in  a  function  that  was  never  coded  in  the 
first  place.  This  is  another  reason  function  or  end 
users  must  participate  in  unit  testing. 

8.2.7  Document  Application  Support  Systems. 

Documentation  has  historically  been  a  weak  link  in 
information  systems  agencies.  In  some  cases,  the 
required  documentation  is  never  written,  or  it  is 
poorly  written.  In  many  cases,  maintenance, 
problem-resolution,  and  enhancement  activity  to  the 
code  itself  is  never  reflected  in  the  original 
documentation  for  the  software  module.  This 
means  that  the  integrity  of  the  documentation  is 
destroyed  over  time.  In  more  than  a  few  cases, 
systems  documentation  becomes  lost,  destroyed,  or 
even  stolen. 

The  solution  to  the  documentation  problem  is 
to  use  software  development  and  test  tools  that 
automatically  generate  the  necessary  documentation 
as  development  proceeds.  Later,  when  code  is 
changed,  the  documentation  is  automatically 
updated  to  reflect  the  change.  A  repository, 
dictionary,  and/or  directory  system  can  also  be  used 
to  control  documentation.  As  a  last  resort,  audits 
can  be  used  to  force  good  documentation 
management. 

Functional  managers  and  process  owners 
should  make  it  a  point  to  demand  a  copy  of  all 
application  and  data  base  documentation  that  affects 
their  area  of  responsibility.  As  maintenance  and 
enhancement  activity  takes  place  on  software  code 
related  to  business  functions,  these  managers  and 
owners  are  in  a  position  to  enforce  good 
documentation  management  principles. 


8.2.8  Review  and  Approve  Application  Systems. 

Application  systems  are  developed  following 
standard  methodologies.  At  the  completion  of  each 
phase  or  milestone  in  the  development  project, 
reviews  and  audits  are  held.  The  final  review 
consists  of  acceptance  tests  conducted  by  the  end 
user  or  customer  of  the  system. 

Throughout  the  entire  application  fulfillment 
process,  software  quality  principles  should  be 
followed.  Functional  users,  managers,  and  process 
owners  should  participate  in  the  quality 
management  and  assurance  process  as  equal 
partners  with  the  technical  elements.  This  concept 
is  fully  a  part  of  the  CIM  initiative. 

The  American  Society  for  Quality  Control 
(ASQC)  maintains  that  the  following  objectives 
should  be  part  of  every  software  development 
effort; 

■  Plan  a  software  development  project  by 
setting  objectives  and  quantitative 
software  quality  goals. 

■  Establish  quality  control  monitoring 
techniques. 

■  Understand  what  defines  good 
engineering  practices  for  ensuring 
software  quality,  verification  and 
validation,  and  increased  productivity. 

■  Define  and  design  implementation  plans 
for  a  software  quality  assurance  program 
based  on  international  and  government 
standards  and  best  commercial  practices. 

When  these  principles  or  objectives  are 
understood  and  followed,  in-process  reviews 
(IPRs)and  audits  tend  to  be  routine  and 
uneventful — just  as  they  should  be. 

8.3  Step  18:  Develop  Data  Base  Structures 

Because  the  information  infrastructure 
consists  of  platforms,  applications,  and  data  base 
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structures  designed  to  work  together  to  satisfy 
enterprise  and  functional  user  requirements, 
portions  of  step  1 8  is  performed  in  parallel  with 
steps  16  and  17.  The  reader  is  reminded  that  the  25 
steps  in  the  framework  methodology  are  not 
necessarily  performed  in  sequence.  In  some  cases, 
steps  are  performed  iteratively,  and  in  other  cases, 
not  at  all.  The  project  manager  has  full  discretion 
on  the  use  of  the  methodology  to  guide  process 
improvement  projects. 

By  the  mid  1960s,  several  concepts  related  to 
data  and  information  began  changing  the  nature  of 
application  development  in  industry  and 
government.  The  first  concept  was  that  of  an  entity. 
An  entity  is  a  person,  place,  thing,  idea,  concept  or 
event.  An  entity  can  be  represented  by  a  data 
element  (or  item)  and  stored  in  a  computer  file 
system.  The  second  concept  was  that  of  attribute. 
An  attribute  is  a  fact  about,  or  characteristic  of,  an 
entity.  The  third  was  that  every  enterprise  deals 
with  a  finite  number  of  entities  and  attributes  which 
can  be  predetermined  by  conducting  a  formal 
business  systems  analysis.  The  fourth  was  that  a 
relationship  exists  among  entities  that  depends  on 
the  nature  of  the  enterprise  and  its  business 
processes;  and  these  relationships  can  be  defined 
and  stored  just  like  entities.  The  fifties  concept  was 
that  data  are  independent  of  the  application 
programs  developed  to  support  business  processes. 

We  have  the  principle  that  data  is  a  corporate 
asset,  and  like  all  assets,  data  must  be  properly 
managed.  Data  base  structures  were  developed  and 
data  base  management  systems  became  available  to 
aid  in  leveraging  the  data  resource  for  the  benefit  of 
the  enterprise  as  a  whole.  An  important  corollary  to 
the  principle  that  data  is  a  corporate  asset  is  that 
organizational  units  do  not  own  the  data  they  create, 
but  rather  must  share  it  with  all  other  units  which 
have  a  legitimate  need  to  access  it.  Access,  privacy, 
and  security  rules  are  part  of  data  base  management. 

If  it  is  true  that  there  are  a  finite  number  of 
data  elements  that  can  be  defined  for  a  given 
enterprise,  and  if  the  enterprise  develops  and 
maintains  data  bases  that  contain  these  data 
elements,  then  it  follows  that  any  number  of 
application  programs  and  systems  can  be 
constructed  to  make  use  of  the  data  resource 


without  the  need  to  create  new  data  elements  or  data 
base  structures  to  contain  them.  An  application 
program  or  system  is  said  to  have  a  view  of  the  data 
base  that  is  sufficient  to  satisfy  application 
requirements.  Therefore,  this  step  of  the 
methodology  is  (or  should  be)  concerned  with 
constructing  an  appropriate  view  of  the  data  base 
rather  than  creating  a  new  data  base. 

Functional  managers  and  users  construct  their 
view  of  data  when  they  build  their  TO-BE  data 
models.  These  data  models  are  part  of  the  FEA 
documentation  package.  From  these  data  models, 
data  base  analysts  can  ensure  that  the  required  data 
does  exist,  and  can  engineer  a  view  that  will  support 
the  needs  of  the  application.  The  view  is 
represented  by  special  systems  software  that  is  used 
by  all  application  programs  to  interact  with  the 
corporate  data  base. 

The  corporate  view  of  data  is  represented  in 
the  enterprise  model.  In  fact,  the  DoD  Enterprise 
Model  defines  the  large  groupings  of  data  (called 
subject  data  bases)  that  are  needed  to  carry  out  all 
defined  mission  areas  in  DoD.  Therefore  all 
application  programs  and  systems  developed  under 
the  enterprise  concept  will  use  portions  of  one  or 
more  subject  data  bases  to  satisfy  business  process 
application  requirements. 

Data  base  technology  has  been  evolving  for 
approximately  40  years.  During  this  period  of  time, 
four  major  classes  of  data  base  systems  have  been 
developed.  Each  succeeding  class  has  proved  to  be 
better  suited  to  serving  overall  corporate  needs. 
However,  all  four  classes  are  still  in  use.  Figure  8-2 
shows  these  classes. 

Business  systems  planning  (described  in  phase 
1  of  the  framework  methodology)  is  concerned  with 
developing  the  data  architecture  for  the  enterprise. 
As  noted  above,  this  can  be  done  apart  from  any 
particular  application  considerations.  The  data 
architecture  is  the  representation  of  the  enterprise 
model  with  respect  to  data  just  as  the  application 
architecture  is  the  representation  of  the  enterprise 
with  respect  to  applications.  The  relationship 
between  business  processes  and  data  and  business 
processes  and  applications  is  notated  in  the 
information  architecture. 
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Figure  8-2.  Generations  of  Data  Base  Systems 


Data  naming  sttindards  and  definitions  are 
generally  stored  in  a  special  purpose  data  base 
called  the  repository  or  data  dictionary.  If  this 
facility  also  identifies  where  specific  data  elements 
can  be  found  in  the  corporate  data  base,  the 
repository  or  dictionary  is  said  to  be  a  directory 
also.  Functional  process  improvement  teams  should 
have  access  to  repository  information  while  they  are 
constructing  their  TO-BE  data  models.  This  way 
the  improvement  team  can  use  standard  naming 
conventions  for  their  data  elements  and  attributes. 
This  saves  considerable  time  and  also  improves 
communications  with  data  administrators  and  data 
base  administrations  who  are  charged  with  the 
responsibility  of  support  functional  requirements  for 
data. 

In  summary,  functional  managers  and  users, 
and  members  of  process  improvement  teams  are  not 
concerned  with  building  data  architectures,  data 
bases,  or  data  repositories,  dictionaries,  and 
directories.  These  are  facilities  that  are  provided  by 
the  technical  staff  for  use  by  functional  elements. 
Functional  personnel  describe  their  data 
requirements  in  the  FEA  and  supporting  documents 


including  TO-BE  data  models.  These  data  models 
are  then  turned  over  to  technical  teams  who  ensure 
that  the  required  data  will  be  made  available  in  the 
proper  formats  to  support  business  process  and 
application  systems  requirements.  Data  models 
themselves  are  stored  in  repositories  to  facilitate 
access  by  technical  staff  as  well  as  other  functional 
elements. 

The  following  tasks  are  performed  in  the 
develop  data  base  stmctures  step: 

■  Review  Approved  FEA  and  Supporting 
Documentation 

■  Review  Technical  Change  Management 
Plan 

■  Assess  Current  Capabilities 

■  Perform  Data  Base  Administration 
Activities 

■  Design  Data  Base  Structures 

■  Unit-test  Data  Base  Structures  with 
Application  Software 

■  Document  Data  Base  Structures 

■  Review  and  Approve  Data  Base 
Structures 
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8.3.1  Review  Approved  FEA  and  Supporting 
Documentation.  The  approved  FEA  along  with  its 
supporting  documentation  specifies  the  data 
requirements  to  support  a  business  process 
improvement  project.  The  Data  Management  Plan 
and  TO-BE  data  models  are  the  principle  documents 
concerned  with  data.  These  documents  should  have 
been  prepared  using  data  architecture  and  repository 
reports  as  reference  material.  If  the  enterprise  has  a 
well-planned,  well-developed  data  base  concept, 
more  than  90%  of  the  needed  data  elements  and 
structures  should  already  exist.  If  this  is  the  case, 
all  that  will  be  needed  is  to  develop  missing  data 
structures  and  then  construct  a  user  view  of  the  data 
resource  appropriate  to  the  improvement  project. 

In  some  cases  (especially  with  major  process 
reengineering  projects),  a  more  important 
consideration  is  the  location  and  distribution  of  data 
to  support  innovations  associated  with  the 
improvement  project.  For  instance,  a  reengineered 
business  process  may  require  a  client/server 
implementation  to  replace  a  mainframe/terminal 
application.  When  this  is  the  case,  the 
organization’s  geo-technical  architecture  will  be 
used  to  help  plan  for  data  distribution  and  use.  Data 
integrity,  security,  and  privacy  as  well  as  concurrent 
data  access  become  important  considerations.  Since 
distributing  data  has  cross-functional  implications, 
this  is  the  most  critical  activity  in  this  task. 

This  task  is  completed  when  both  functional 
and  technical  elements  agree  on  the  basic 
requirements  for  data  in  support  of  the  business 
process  improvement  project.  Once  this  agreement 
is  reached,  data  administration  and  data  base 
management  technical  staff  become  responsible  for 
putting  the  necessary  facilities  into  place. 

8.3.2  Review  Technical  Change  Management 
Plan.  Data  is  a  shared  corporate  resource.  This 
means  that  the  requirements  for  data  in  support  of  a 
specific  business  process  or  application  must  be 
rationalized  with  the  requirements  for  data  for  other 
processes  and  applications  all  the  while  maintaining 
the  integrity  of  the  data  base  system  as  a  corporate 
asset.  The  Technical  Change  Management  Plan  is 
the  vehicle  for  doing  this.  As  described  in  the 
previous  step,  this  plan  consolidates  the 


requirements  associated  with  all  active  functional 
and  technical  improvement  projects.  This  helps  the 
technical  staff  ensure  that  a  change  in  one  area  of 
the  data  base  system  in  support  of  one  improvement 
project  will  not  adversely  affect  production  data 
bases  or  changes  being  made  in  support  of  other 
improvement  projects. 

Functional  and  technical  elements  must  work 
together  to  review  the  Technical  Change 
Management  Plan  with  respect  to  each 
improvement  project.  This  is  necessary  because 
invariably,  compromises  must  be  made  to  maintain 
the  integrity  of  the  data  base  system  from  the 
corporate  perspective.  For  example,  one 
improvement  project  may  call  for  relocating  a  class 
of  data  from  one  technical  platform  to  another.  But 
existing  applications  may  require  the  data  to  remain 
where  it  is.  Technical  staff  can  always  work  out  an 
acceptable  solution  providing  they  work  closely 
with  the  functional  elements  involved  in  the  change. 

This  task  is  completed  when  both  functional 
and  technical  elements  agree  on  a  data  deployment 
plan  that  is  satisfactory  for  all  concerned  parties. 

8.3.3  Assess  Current  Capabilities.  In  a  well 
managed  technical  agency,  all  data  structures, 
components,  and  platforms  will  be  represented  in 
the  geo-technical  architecture.  This  architecture 
show  how  all  information  resources  are  distributed 
and  deployed.  The  geo-technical  architecture 
should  also  indicate  which  business  processes  and 
supporting  applications  use  components  of 
deployed  resources.  In  other  words,  the  geo¬ 
technical  architecture  is  a  guide  to  understanding 
the  interoperability  and  data  sharing  characteristics 
of  the  information  management  resource. 

All  changes  to  the  geo-technical  architecture 
as  a  result  of  approved  functional  and  technical 
improvements  must  be  carefully  considered  to 
eliminate  the  potential  problems  associated  with 
making  structural  changes  in  an  operational  facility. 
Again,  variances  and  compromises  may  be 
necessary  to  maintain  the  integrity  of  the  corporate 
information  resource  as  well  as  reduce  the 
probability  of  waste  and  redundancy  of  technical 
assets.  Functional  and  technical  elements  must 
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work  together  throughout  the  first  three  tasks  in  this 
step. 

This  task  is  complete  when  functional  and 
technical  elements  are  in  full  agreement  as  to  how 
to  proceed  with  making  changes  and  enhancements 
to  the  data  resource  to  support  the  requirements  of 
all  approved  improvement  projects  in  the  context  of 
maintaining  a  corporate  focus  on  the  data  resource. 

8.3.4  Perform  Data  Base  Administration 
Activities.  Once  plans  are  in  place  and  all  conflicts 
related  to  the  data  resource  are  resolved,  the  next 
task  is  to  complete  data  administration  activities. 
Data  administration  is  considered  to  be  the 
custodian  of  the  data  resource  and  performs  a 
stewardship  role  in  making  data  resources  available 
to  all  authorized  components  in  the  enterprise.  Data 
administration  is  concerned  with  data  as  a  corporate 
resource,  while  data  base  administration  is 
concerned  with  the  physical  storage,  stracture,  and 
distribution  of  data. 

Data  administration  is  charged  with  the 
responsibility  of  maintaining  the  integrity  of  the 
DoD  Enterprise  Model  with  respect  to  the  data 
resource,  and  ensuring  that  the  strategic  plan  for 
data  management  is  carried  out.  Data 
administrators  also  serve  as  the  interface  between 
functional  users  and  data  base  administration. 
Specific  data  administration  functions  include  the 
following: 

■  Assisting  functional  users  in  constructing 
effective  data  models  and  detining  or 
selecting  entities,  attributes,  and 
relationships 

■  Defining  data  base  security,  privacy,  and 
integrity  rules 

■  Providing  effective  means  of  accessing 
data  bases  especially  in  client/server 
environments  and  with  the  use  of  4GLs 

■  Overseeing  the  development  and 
maintenance  of  data  repositories, 
dictionaries,  and  directories. 

■  Providing  logical  data  base  designs  (user 
views) 


■  Conducting  data  base  audits  to  ensure 
that  the  integrity  of  the  data  structures  is 
maintained  and  that  adequate  audit  trails 
and  backup  and  recovery  schemes  are  in 
place 

■  Ensuring  that  data  base  performance 
characteristics  are  adequate  with  respect 
to  process  requirements  and  customer 
expectations 

■  Define  and  enforce  data  entity,  attribute, 
and  relationship  naming  conventions, 
primary  and  secondary  access  rules  and 
keys,  and  edit  and  validation  rules 

■  Provide  and/or  conduct  functional 
training  in  data  base  management 
concepts  and  facilities,  and  provide  end 
user  consulting,  facilitation,  and  support. 

In  organizations  moving  to  object  orientation, 
data  administration  will  assist  in  the  definition  and 
structuring  of  objects  in  the  data  base.  Data  base 
objects  are  far  more  robust  than  data  tables  used  in 
relational  data  bases,  and  record  structures  used  in 
network  and  hierarchical  data  bases. 

This  task  is  complete  when  data 
administration  reviews  and  approves  the  data 
management  plan  and  certifies  that  all  standards  and 
conventions  are  being  observed  in  data  models  and 
user  views;  and  that  all  security,  privacy,  and 
integrity  safeguards  are  in  place. 

8.3.5  Design  Data  Base  Structures.  The  outputs 
of  data  administration  are  stored  in  repositories, 
dictionaries,  and  directories  and  as  documentation. 
Data  administration  is  said  to  work  with  metadata, 
which  is  data  about  data.  Data  base  administration, 
however,  is  concerned  with  managing  the  actual 
instances  of  data  entities,  attributes,  and 
relationships.  From  the  outputs  of  data 
administration,  data  base  administrators  oversee  the 
construction  and  distribution  of  data  bases,  the 
management  and  use  of  specialized  data  base 
management  system  software,  and  the  development 
of  software  components  that  represent  data  base 
views,  and  with  using  a  variety  of  data  base  utilities 
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to  maintain  the  integrity  and  performance 
characteristics  of  the  facility. 

In  general,  functional  users  do  not  work 
directly  with  data  base  administrators  except  to 
consult  on  specific  data  base  related  situations.  It  is 
helpful,  though,  for  functional  elements  to 
understand  what  data  base  administrators  do.  The 
functions  of  data  base  administration  include  the 
following: 

■  Structuring  data  and  loading  (populating) 
data  bases  with  all  instances  of  data 
entities,  attributes,  and  relationships 

■  Distributing  data  bases  according  to  the 
geo-technical  architecture  and  data 
management  plan 

■  Restructuring  or  reorganizing  data  bases 
in  support  of  improvement  projects 

■  Calculating  data  storage  requirements 
and  ensuring  adequate  capacity  to 
support  process  and  application 
requirements 

■  Selecting  access  paths  to  data  structures 
and  providing  utilities  or  routines  as 
necessary  to  provide  access 

■  Monitoring  the  performance  of  the  data 
base  and  taking  appropriate  action  to 
maintain  performance  standards 
especially  for  on-line  access  and 
transaction  systems 

■  Enforcing  data  normalization  rules  to 
prevent  data  base  anomalies  from 
occurring  that  may  compromise  data 
base  integrity. 

Data  normalization  is  concerned  with 
following  certain  rules  in  structuring  data  bases  to 
eliminate  unnecessary  data  redundancy,  prevent 
corruption  of  data  structures,  and  ensure  that 
structural  relationships  maintained  in  the  data  base 
reflect  reality. 


Data  base  administrators  are  also  called  upon 
to  construct  test  data  bases  that  can  be  used  with 
prototypes  and  as  test  beds  for  unit  and  systems 
testing  during  application  development. 

Data  base  administration  is  an  on-going 
activity  but  there  are  two  checkpoints  that  are 
important  from  a  process  improvement  perspective. 
The  first  is  when  data  base  administration  is  able  to 
construct  a  suitable  data  base  to  support  prototyping 
activities.  The  second  is  when  data  base 
administration  is  able  to  construct  a  fully  tested 
production  data  base  in  support  of  an  operational 
application  system. 

8.3.6  Unit-test  Data  Base  Structures  with 
Application  Software.  Task  8.2.6  in  the  previous 
step  calls  for  unit  testing  of  application  modules  or 
programs.  This  is  the  complementary  task  that 
provides  a  test  data  base  to  support  unit  testing. 
While  the  application  program  is  being  tested  for 
structural  and  logic  errors,  data  base  administration 
is  testing  the  data  base  structure  as  well.  In  general, 
during  this  task,  all  elements  of  the  data  base  can  be 
tested  except  for  performance  under  load 
conditions. 

Functional  users  are  generally  not  concerned 
with  developing  test  data  bases  to  support  unit 
testing  except  in  the  capacity  of  review  and 
validation  of  test  data  base  results. 

83.7  Document  Data  Base  Structures.  Because 
the  data  base  system  is  a  critical  corporate  asset,  it 
is  imperative  that  all  documentation  related  to  the 
data  base  system  be  accurate  and  up-to-date. 
Fortunately,  most  data  base  management  software 
generates  documentation  as  a  by-product  of 
construction  and  maintenance  activities.  If  a 
repository  or  dictionary  system  is  in  place,  all 
activities  with  respect  to  metadata  management  will 
also  be  automatically  documented.  In  addition,  if 
the  repository  and  or  dictionary  system  is  active 
with  respect  to  the  data  base  system,  the  software 
ensures  that  the  structures  defined  in  the  dictionary 
system  are  exactly  the  same  as  the  structures 
existing  in  the  data  base  files. 

Functional  elements  are  generally  not 
concerned  with  this  task  other  than  to  reference  the 
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documentation  associated  with  repositories, 
dictionaries,  and  physical  data  base  systems. 
Functional  users  may  want  to  assure  themselves  that 
all  referenced  documentation  is  indeed  accurate 
before  using  such  documentation  in  their  business 
process  improvement  project. 

8.3.8  Review  and  Approve  Data  Base  Structures. 

The  final  task  in  this  step  consists  of  a  formal 
review  and  approval  of  the  actions  that  will  be  taken 
with  respect  to  data  administration  and  data  base 
administration  to  provide  data  resources  in  support 
of  business  process  improvement  projects  within  the 
context  of  maintaining  an  enterprise  view  of  the 
data  facility.  This  task  can  be  performed  following 
concurrently  with  acceptance  of  the  results  of  unit 
testing  of  all  application  software  in  support  of 
improvement  projects. 

Figure  8-3  is  an  extension  of  figure  8-1  and 
shows  the  relationships  of  the  steps  in  enterprise 
engineering.  After  the  completion  of  steps  8.1,  8.2, 
and  8.3  for  all  current  projects,  improvement 
projects  are  ready  to  move  to  the  implementation 
step.  At  this  point,  an  acceptable  course  of  action 
has  been  engineered,  and  it  is  time  to  prepare  the 


organization  for  implementation  and  deployment  of 
the  reengineered  business  process  and  associated 
technical  changes. 

As  figure  8-3  illustrates,  step  8.5  is  the  point  at 
which  all  current  efforts  are  consolidated  with 
respect  to  changes  in  the  technical  infrastructure. 
The  CM  objectives  of  enterprise  modeling, 
interoperability,  and  shared  data  require  this 
synchronization  point  so  that  changes  can  be  made 
in  the  technical  infrastructure  without  jeopardizing 
operational  systems.  This  implies  some  degree  of 
batching  changes  and  enhancements  so  that 
coordination  can  be  maintained. 

8.4  Step  19:  Construct  Information  Systems 

This  step  is  concerned  with  constructing  an 
operational  information  system  in  accordance  with 
the  approved  FEA  and  within  the  context  of  the 
technical  change  management  plan.  The  modules 
and  programs  developed  earlier  are  assembled  into 
a  working  system  and  tested  against  a  representative 
test  data  base.  At  this  time,  all  changes  in  the 
organizational  change  management  plan  are 
reviewed  and  revised  as  necessary  to  conform  with 
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the  way  the  information  system  will  operate. 
Organizational  changes  can  be  in  the  areas  of 
management,  structural  alignment,  formation  of 
work  teams,  customer/supplier  partnerships,  and 
recognition  and  reward  systems.  Policies, 
procedures,  special  forms,  and  report  formats  are 
developed  which  bring  the  process  in  alignment 
with  the  information  system. 

At  the  completion  of  this  step,  a  full  systems 
audit  will  be  performed,  and  extensive  customer 
acceptance  tests  will  be  completed.  After 
acceptance,  the  finished  system  will  be  ready  for 
integration  activities  and  deployment.  Integration 
activities  are  performed  in  the  next  step  in  the 
enterprise  engineering  phase,  while  deployment  is 
conducted  in  the  next  phase  of  the  methodology — 
Project  Execution. 

The  reader  is  reminded  that  a  technical  change 
management  plan  is  one  of  the  documents  that 
guides  information  system  specification,  design, 
and  development  in  support  of  FEA  requirements. 
One  of  the  key  purposes  of  the  technical  change 
management  plan  is  to  address  migration  and 
integration  issues  early  in  the  systems  development 
process.  Therefore,  when  this  step  is  completed  and 
the  system  moves  to  the  next  step — systems 
integration — most  of  the  issues  associated  with 
legacy  systems,  migration  systems,  and  integration 
and  interoperability  will  already  be  resolved. 

Systems  construction  is  primarily  the 
responsibility  of  the  technical  staff.  But  functional 
staff  including  process  owners,  improvement  team 
project  managers,  and  key  functional  users  must  be 
fully  involved  throughout  the  construction  process 
to  ensure  that  expectations  will  be  met  and 
discrepancies  discovered  as  soon  as  possible.  Many 
project  failures  including  cost  overmns  and 
untimely  delivery  can  be  traced  to  the  non¬ 
involvement  of  functional  elements  in  systems 
construction. 

The  following  tasks  are  performed  in  the 
construct  systems  step: 

■  Prepare  Test/Pilot  Site  for  Systems 
Assembly 

■  Load  Test  Files  and  Data  Bases 


■  Assemble  and  Test  Application  Systems 

■  Develop  Draft  Information  System 
Manuals 

■  Conduct  Initial  Training 

■  Conduct  Acceptance  Trials 

■  Develop  Data  Acquisition  Plan 

■  Review/Revise  Organizational  Change 
Management  Plan 

■  Develop  Final  Documentation  Package 

■  Acquire/Develop  Functional/Technical 
Training  Systems 

■  Conduct  Systems  Audit  and  Acceptance 
Tests 

8.4.1  Prepare  Test/Pilot  Site  for  Systems 
Assembly.  The  first  task  in  systems  construction  is 
to  prepare  a  test  or  pilot  site  suitable  for  assembling 
the  final  information  system  and  completing  all  test 
activities.  The  test  platform  should  be  as 
representative  as  possible  of  the  hardware  and 
communications  systems  that  will  be  utilized  or 
deployed  during  systems  installation. 

If  some  components  of  the  platform  will  not 
be  available  due  to  procurement  situations,  physical 
site,  or  technical  problems,  arrangements  can 
usually  be  made  to  borrow,  rent,  or  lease  equipment. 
Such  arrangements  can  be  made  with  other 
agencies,  service  bureaus,  third-party  lessors,  or 
with  the  equipment  vendor.  If  any  part  of  the 
specified  platform  will  not  be  available  during  this 
step  and  portions  of  system  assembly  and  test  must 
be  simulated,  the  project  manager  must  schedule 
additional  time  in  the  deployment  (project 
execution)  phase  of  the  project  for  final  testing  and 
error  correction. 

While  much  assembly  and  testing  can  be 
performed  on  workstations  equipped  with 
computer-aided  software  engineering  (CASE)  tools, 
final  acceptance  can  never  be  granted  until  tests  are 
completed  on  a  live  platform. 

8.4.2  Load  Test  Files  and  Data  Bases.  Systems 
assembly  and  testing  must  be  performed  using 
statistically  valid  test  data.  This  data  must  be  stored 
in  file  and  data  base  structures  that  match  data  base 
specifications.  If  test  data  bases  cannot  be 


8-24 


Enterprise  Engineering  -  (Rev.  5.2:  1  DEC  94) 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


constructed  by  extracting  data  from  live  or 
production  data  bases,  then  representative  test  data 
must  be  generated.  Software  utility  programs  exist 
to  facilitate  this  effort.  The  technical  staff  should 
make  every  effort  to  acquire  production  quality  data 
prior  to  final  systems  audit  and  customer  acceptance 
testing.  If  this  is  not  possible,  then  the  project 
manager  must  allocate  additional  test  time  during 
the  installation  and  deployment  phase  of  the  project. 

Often  production  quality  data  is  not  available 
at  this  stage  of  systems  development  either  because 
it  does  not  exist,  exists  but  is  not  structured  as  data 
base  specifications  call  for,  or  has  not  been 
scrubbed.  Scrubbing  refers  to  the  process  of 
reviewing  existing  data  and  reformatting  it  for  use 
in  a  new  information  system.  Existing  data  may  be 
corrupted  (invalid),  unnormalized  (ambiguous), 
wrongly  formatted,  contain  redundancies,  missing 
search  and  access  keys,  and/or  missing  critical 
attributes  needed  in  the  new  information  system. 
Data  scrubs  can  be  laborious  and  time  consuming 
operations  when  high  volumes  of  data  are  involved. 

Even  when  good  data  is  available  for 
information  system  assembly  and  test,  it  may  not  be 
available  in  production  quantity.  This  means  that 
accurate  capacity  and  performance  tests  cannot  be 
reliably  performed.  Again,  if  this  is  the  case, 
additional  test  time  must  be  allocated  prior  to 
installation  and  deployment.  Some  information 
systems  perform  well  under  test  conditions,  but  fail 
under  production  conditions. 

8.4.3  Assemble  and  Test  Application  Systems. 

This  is  usually  the  most  time  intensive  task  in 
systems  construction.  All  of  the  components, 
modules,  objects,  and  programs  developed  and  unit 
tested  earlier  must  now  be  assembled  and  tested  as 
subsystems  and  systems.  At  this  time,  application 
software  is  tested  in  a  live  systems  software 
environment  and  under  production  platform 
conditions.  During  this  period,  functional  users  will 
be  called  upon  to  review  and  validate  features  and 
functions  of  the  information  systems  once  they  pass 
initial  tests  by  the  technical  staff. 

Most  information  systems  are  assembled 
according  to  the  system  of  menus  that  will  be  in 
place  when  the  system  is  finished.  Assuming  good 


design,  each  major  and  most  minor  features  and 
functions  can  be  tested  independently.  This  is 
especially  true  in  client/server  application 
environments  or  when  object  oriented  systems  are 
being  developed. 

A  well  designed  assembly  and  test  plan  will 
call  for  common  or  high  use  components  (or 
subsystems)  to  be  assembled  and  tested  first, 
followed  by  assembly  and  test  of  software  that 
supports  little  used  or  special  purpose  features.  It  is 
also  helpful  if  the  assembly  and  test  plan  correlates 
to  the  natural  sequence  that  end  users  will  employ 
when  they  are  using  the  system.  This  way,  users 
can  better  relate  information  systems  features  to  the 
business  process  operations  they  support. 

A  systems  test  checklist  will  include  at  least 
the  following  elements: 

■  Who  is  responsible  for  testing/validating 
a  subsystem/system? 

■  What  data  is  needed  for  the  test  and 
where  does  it  enter  the  system? 

■  What  inputs/triggers  are  needed  and  what 
is  the  source? 

■  What  resources/components  will  this  test 
exercise? 

■  What  outputs/screens/responses  are 
required? 

■  What  acceptance/validation  criteria  will 
be  used  and  who  provides? 

■  Who  is  responsible  for  review  test  results 
and  granting  acceptance? 

8.4.4  Develop  Draft  Information  Systems 
Manuals.  Good  practice  calls  for  the  development 
of  supporting  documentation  in  parallel  with  the 
development  of  information  systems.  This  ensures 
that  the  documentation  is  done  and  done  right. 

Better  practice  calls  for  the  development  of 
supporting  documentation  before  information 
systems  development  which  allows  the 
documentation  to  serve  as  a  validation  mechanism. 
As  stated  earlier  many  software  engineering  and  test 
tools  provide  at  least  some  documentation  as  a  by¬ 
product.  In  any  case,  functional  users  should  insist 
on  the  presence  of  an  acceptable  documentation 
plan  as  part  of  the  systems  construction  process. 
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In  general,  three  classes  of  information 
systems  related  documentation  are  required: 

■  Systems  documentation.  This  is  the 
documentation  needed  by  technical  staff 
to  maintain,  support,  repair,  and  enhance 
all  hardware,  software,  and  data  base 
components  of  the  information  system. 

It  is  in  the  interests  of  functional  users  to 
know  that  such  documentation  will  be  in 
place  to  support  maintenance  and 
customer  service  activities. 

■  Operations  documentation.  This  is  the 
documentation  needed  by  operations  and 
production  staff  to  support  production 
activities.  Of  special  importance  is  the 
documentation  needed  to  support 
network  and  communications  services  in 
support  of  the  information  system.  This 
class  of  documentation  also  includes  that 
needed  to  support  such  utilities  as  file 
backup,  restore  and  recovery  operation, 
and  audit  and  performance  measurement 
operations. 

■  User  documentation.  This  is  the 
documentation  needed  by  functional 
users,  internal  and  external  customers, 
suppliers,  and  other  stakeholders  affected 
by  or  supported  by  the  information 
system.  Great  strides  have  been  made  in 
recent  years  in  improving  the  utility  and 
maintainability  of  user  documentation. 
Multi-media,  hypertext,  on-line 
contextual  help  systems,  CD-ROM,  and 
user  friendly  user  texts  are  becoming 
common. 

A  final  consideration  for  functional  users  in 
this  task  is  to  ensure  that  a  program  of  document 
maintenance  will  be  in  place  so  that  documentation 
does  not  become  obsolete  or  counter-productive  due 
to  changes  in  the  information  system. 

8.4.5  Conduct  Initial  Training.  Before  functional 
users  can  fully  participate  in  systems  testing  and 
acceptance,  they  must  receive  initial  training  in  the 
use  of  the  system.  Since  formal  training  programs 
cannot  be  put  into  place  until  the  information 


system  is  complete  and  relatively  stable,  initial 
training  is  usually  ad  hoc  or  informal  and  conducted 
by  members  of  the  technical  staff.  Also,  formal 
training  systems  development  is  expedited  once 
documentation  is  in  place. 

The  initial  training  task  affords  an  opportunity 
to  begin  the  formal  training  systems  development 
process.  Professional  training  systems  developers 
should  participate  in  initial  training  sessions  in 
order  to  collect  data  useful  for  training  system 
specification  and  design.  (They  should  also  work 
with  the  documentation  staff  for  the  same  reason.) 
Training  staff  members  should  also  work  with  users 
during  the  testing  period  to  discover  the  elements  of 
the  system  that  may  need  special  attention  in 
training.  Often  a  member  of  the  training 
development  staff  serves  as  one  of  the  members  of 
the  test  and  acceptance  team  to  gain  first-hand 
experience  with  the  system. 

Since  initial  training  sessions  are  often 
incomplete  or  less-than-desirable,  it  is  helpful  at  this 
time  to  institute  a  user  help  facility  or  telephone 
hot-line  so  that  initial  users  can  quickly  get 
questions  answered,  problems  solved,  and  provide 
useful  input  to  the  technical  staff.  Members  of  the 
documentation  and  training  development  staff 
should  routinely  receive  a  copy  of  all  hot-line  calls 
and  responses,  as  well  as  all  discrepancy  reports. 

The  help  facility  or  hot-line  will  be  much 
more  effective  if  it  can  be  implemented  using  e- 
mail,  groupware,  or  bulletin  board  facilities.  This 
way,  all  communications  are  in  writing  both  ways, 
and  interested  parties  can  easily  be  included  as 
message  recipients.  In  addition,  these  facilities 
offer  a  means  of  conducting  ad  hoc  conferences  to 
solve  problems  and  address  issues. 

8.4.6  Conduct  Acceptance  liials.  At  this  point,  in 
the  construction  step,  the  technical  staff  has  made 
sufficient  progress  in  systems  assembly  and  initial 
testing  to  permit  user  acceptance  trials  to  begin. 
Users  have  received  initial  training  and  at  least 
some  draft  documentation  and  are  prepared  to 
effectively  participate  in  testing  and  acceptance. 
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While  initial  user  testing  can  be  performed  at 
any  time,  formal  acceptance  trials  should  only  be 
conducted  on  a  subsystem  basis  and  in  accordance 
with  a  formal  and  approved  test  plan.  The  test  plan 
will  include  the  features  and  functions  to  be  tested; 
the  validation  criteria;  sample  outputs,  screens, 
forms,  and  reports;  and  appropriate  checklists. 

Since  most  information  systems  are  designed  to 
support  various  levels  of  users  (managers, 
professional,  clerical,  customers,  etc.) 
representatives  from  each  group  should  participate 
in  the  testing  process. 

In  addition  to  actual  users,  the  test  team  should 
include  at  least  one  person  who  is  trained  and 
experienced  in  systems  testing  procedures.  Such  a 
person  knows  how  to  exercise  all  features  and 
functions,  simulate  a  wide  range  of  error  conditions, 
and  intentionally  crash  a  systemthings  a  typical  user 
would  not  attempt  to  do. 

Professional  staff  is  also  required  to  test  the 
security,  privacy,  integrity,  performance,  capacity, 
backup,  recovery,  maintenance,  and  utility  features 
of  an  information  system. 

A  formal  test  program  will  include  an 
extensive  regression  testing  protocol  to  ensure  that 
changes  to  components  of  the  system  will  not 
invalidate  previous  tests  on  those  components. 

Once  subsystems  are  tested  independently,  they 
must  be  retested  as  they  are  assembled  into  higher 
level  systems.  The  final  acceptance  test  of  the 
information  system  itself  is  conducted  once  all 
assembly  work  is  complete,  all  major  discrepancies 
corrected,  and  all  minor  discrepancies  under 
control. 

8.4.7  Develop  Data  Acquisition  Plan.  At  this 
point  in  the  construction  step  (or  sometime  during 
the  acceptance  trials),  a  data  acquisition  plan  must 
be  formalized  so  that  by  the  time  the  information 
system  is  ready  for  installation  and  deployment,  a 
fully  populated,  valid  data  base  with  all  supporting 
files  will  be  in  place.  The  amount  of  time  and  labor 
needed  to  ensure  production  quality  data  will 
depend  on  the  current  situation  with  respect  to 
existing  (legacy)  information  systems,  and  the 
effectiveness  of  the  data  administration  program  as 
it  affects  the  information  system  in  question.  The 


time  period  to  complete  this  task  can  extend  from 
several  days  to  several  months.  An  accurate 
estimate  of  the  level  of  effort  will  be  possible 
following  a  review  of  the  data  management  plan 
produced  much  earlier  in  the  methodology. 

In  general,  the  needed  data  will  be  available 
from  one  or  more  of  the  following  sources  listed  in 
increasingly  level  of  difficulty: 

■  An  existing  and  compatible  data  base 
which  can  easily  be  converted  to  the 
format  specified  by  data  base 
administration 

■  An  existing  file  system  where  data  can 
be  restractured  into  data  base  formats 

■  A  disparate  (dispersed)  set  of  files  which 
will  require  program  support  to  reformat 
and  restracture 

■  Manual  records  which  will  have  to  be 
scanned  and  scrubbed 

■  New  data  which  will  have  to  be  located 
and  encoded. 

The  time  required  to  execute  the  data 
acquisition  plan  will  depend  on  the  format  the  data 
is  in,  the  quality  of  the  data,  and  the  amount  of  data. 
In  addition,  new  information  systems  are  able  to 
work  with  data  in  multiple  media  including  voice 
and  image  where  image  can  refer  to  video  tape, 
film,  photographs,  charts  and  graphs,  and  computer 
generated  images.  The  data  acquisition  plan  must 
take  requirements  for  multi-medial  formats  into 
consideration. 

8.4.8  Review/Revise  Organizational  Change 
Management  Plan.  The  organizational  change 
management  plan  prepared  earlier  in  the 
methodology  was  based  on  assumptions  about  how 
the  improved  (reengineered)  process  would  work, 
and  the  features  and  functions  of  the  supporting 
information  systems.  It  is  likely  that  at  this  point, 
given  the  progress  made  in  implementing  process 
and  technical  changes,  that  the  organizational 
change  management  plan  will  need  to  be  reviewed 
and  revised  to  accommodate  necessary  specification 
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and  design  changes.  Sufficient  data  should  now  be 
available  by  this  point  to  allow  the  oiganizational 
plan  to  be  refined  to  almost  final  form.  Please  note 
that  the  organizational  change  management  plan 
will  be  used  in  the  project  execution  phase  as  a 
guide  to  making  organizational  changes  needed  to 
support  the  reengineered  process  and  all  supporting 
information  systems. 

Some  of  the  areas  in  the  plan  that  may  have 
been  affected  by  progress  to  date  include  the 
following: 

■  Policy,  procedures,  directives,  and  other 
guidance  documents 

■  Management  roles,  responsibilities,  and 
span  of  control 

■  Management  controls  and  performance 
monitoring  systems 

■  Audit,  oversight,  and  inspection 
protocols 

■  Departmental  and  work  group 
organization  and  structure 

■  Work  structure,  work  flow  and  work 
routines 

■  Facilities,  floorplans,  office 
arrangements,  and  support  services 

■  Public  relations  publications  and  support 
services 

■  Employee  qualification,  hiring,  and 
training  requirements 

■  Upgrading  employee  technical  skills  (to 
use  new  systems) 

■  Job  classification  and  job  description 
documents 

■  Employee  recognition  and  reward 
systems 

■  Employee  and  stakeholder  transition  and 
communications  plans 

■  Customer  service  and  support  systems 

■  Supplier  and  other  stakeholder  support 
systems 

■  Total  quality  and  continuous 
improvement  program 

This  task  is  complete  when  functional 
management  is  assured  that  a  workable 
organizational  change  management  plan  is  in  place 
(or  will  be  in  place)  to  support  the  installation  and 
deployment  of  the  improved  business  process  and 


information  systems  support.  Note  that  this  is  still  a 
planning  task.  The  implementation  of  the  plan  will 
be  during  the  project  execution  phase. 

8.4.9  Develop  Final  Documentation  Package. 

With  acceptance  trials  complete  or  nearly  so,  and 
with  an  updated  organizational  change  management 
plan,  it  is  possible  to  develop  the  final 
documentation  package  that  supports  both  the 
improved  process  and  the  new  information  system. 

Draft  information  systems  manuals  can  go 
through  final  updates  and  edits  in  preparation  for 
supporting  the  project  execution  phase.  Because 
additional  changes  to  the  information  system  can  be 
expected  during  the  installation  and  deployment 
period,  creating  excess  inventory  should  be  avoided. 

Documentation  related  to  process  operations 
and  related  organizational  support  functions  can 
now  be  written  and  tested.  Documentation  will  be 
needed  for  most  of  the  items  noted  in  the  previous 
task.  As  with  systems  manuals,  final  updates  and 
edits  can  be  expected  during  the  project  execution 
phase. 

This  is  also  the  time  the  technical  staff  should 
be  assembling  the  technical  documentation  related 
to  all  components  of  the  information  system  that 
will  be  needed  for  trouble-shooting,  maintenance, 
and  continuous  enhancements. 

Personnel  responsible  for  preparing  the  final 
documentation  package  should  do  their  job  as  if 
they  were  contractors  expected  to  turn  over  an 
acceptable  documentation  package  to  the  customer 
Functional  management  should  insist  on  adherence 
to  good  documentation  standards  even  in  the 
technical  areas. 

8.4.10  Acquire/Develop  Functional/Technical 
IVaining  Systems.  \V^th  a  functioning  system, 
organizational  policies  and  procedures  specified, 
and  a  documentation  package  in  final  editing  stages, 
the  training  activity  can  acquire  or  develop  the 
necessary  training  packages  to  support  the  new 
business  process  and  its  related  information  system 
support  components.  The  training  system  should  be 
scheduled  for  completion  in  time  to  support 
installation  and  deployment  activities.  Since 
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deployment  will  most  likely  be  phased,  the  initial 
installations  can  serve  as  a  final  test  site  for  the 
training  program. 

At  this  time  it  is  also  possible  to  estimate  how 
many  trainees  will  go  through  the  training  program, 
their  locations,  and  the  time  frame  for  completing 
training.  With  this  information,  training  system 
planners  can  estimate  resource  requirements, 
number  of  instructors  or  facilitators,  out-sourcing 
needs,  and  materials  costs.  This  data  will  be  used  in 
the  next  phase  to  plan  the  training  delivery  program. 

Consideration  should  be  given  to  using  media- 
based  training  and  distance  learning  concepts  where 
practical  or  as  a  supplement  to  instructor-based 
training.  All  training  techniques  and  methods 
should  have  a  hands-on  component  so  training 
audiences  can  develop  skills  in  working  in  the  new 
process  and  with  the  new  information  systems  that 
support  them. 

8.4.11  Conduct  Systems  Audit  and  Acceptance 
Tests.  With  all  elements  of  the  information  systems 
support  in  place  including  training  courses  and 
documentation  packages,  functional  users  can 
conduct  a  final  audit  and  perform  final  acceptance 
tests.  Once  the  information  system  is  certified  by 
the  functional  elements,  the  project  can  move  to  the 
next  step — ^Design  the  Systems  Migration  and 
Integration  Plan. 

8.5  Step  20:  Design  Systems  Integration  Plan 

The  construction  of  information  systems  is  a 
risk-filled,  expensive,  complex  undertaking.  This  is 
true  even  in  a  strict  stovepipe  organizational 
environment.  When  the  objectives  of 
interoperability  and  enterprise-wide  data  sharing 
(enterprise  integration)  are  added,  information 
systems  projects  become  even  more  complex.  The 
fact  is  that  information  systems  are  built  one  at  a 
time  according  to  specifications  whether  the 
approach  used  is  traditional  (waterfall  method)  or 
rapid  prototyping.  The  initial  objective  must  be  to 
deliver  an  acceptable  information  system  to  the 
customer  on  time  and  within  budget.  This  alone  is  a 
most  challenging  objective  and  seldom  realized  in 
all  aspects.  Once  that  objective  is  accomplished, 
efforts  can  be  undertaken  to  integrate  that 


information  system  into  the  technical  infrastructure 
in  such  a  way  that  enterprise-wide  objectives 
including,  but  not  limited  to,  interoperability  and 
data  sharing  can  be  realized. 

The  existence  of  enterprise  models,  standard 
architectures  (information,  application,  data,  and 
geo-technical),  and  rigorous  configuration 
management  helps  ensure  up-front  that  information 
systems  designs  are  such  that  effective  integration 
can  be  accomplished  in  a  reasonable  manner. 

The  enterprise  model  is  developed  based  on  an 
organization’s  mission,  vision,  goals,  objectives, 
values,  beliefs,  and  strengths.  It  is  a  function  of 
business  oriented  model.  Standard  architectures  are 
developed  based  on  an  oiganization’s  current 
inventory  of  machines,  applications,  and  data. 

AS-IS  architectures  describe  the  legacy  systems  and 
components  that  provide  a  base  for  improvement 
and  enhancement.  TO-BE  architectures  define  the 
vision  of  what  the  technical  infrastructure  is  to 
become.  Configuration  management  helps  ensure 
that  progress  from  the  AS-IS  to  the  TO-BE  is 
consistent.  Migration  systems  provide  a  means  of 
moving  in  an  orderly  fashion  from  the  baseline  or 
legacy  environment  to  the  objective  or  TO-BE 
environment.  In  DoD,  the  TO-BE  environment  is 
one  of  open  systems  and  enterprise-wide  support. 

It  is  critical  to  note  that  the  enterprise  model 
and  technical  architectures  are  built  apart  from 
business  process  reengineering  and  information 
systems  development  projects.  This  implies  that 
both  reengineering  and  systems  development  are 
expected  to  conform  to  the  requirements  of  models 
and  architectures,  not  the  other  way  around. 

Information  systems  development  can  proceed 
in  any  one  of  three  ways: 

■  A  legacy  system  can  be  upgraded  to 
provide  new  features  and  functions 
needed  to  support  a  reengineered 
business  process.  However,  if  major 
changes  are  made  to  a  business  process 
(radical  reengineering),  it  is  highly 
doubtful  that  a  legacy  system  can  be 
improved  enough  to  support  the  new 
process.  It  is  usually  more  cost-effective 
to  start  over. 
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■  A  designated  migration  system  can  be 
redesigned  to  support  the  reengineered 
business  process.  This  is  more  likely  to 
succeed  if  the  designed  migration  system 
is  identified  before  an  FEA  is  prepared. 

It  must  also  be  remembered  that  a 
migration  system  usually  is  designed  to 
replace  two  or  more  legacy  systems. 

This  means  that  updates  to  a  migration 
system  to  support  one  reengineered 
business  process  cannot  be  such  that  the 
migration  system  will  cease  to 
adequately  support  its  other  business 
processes.  For  this  reason,  it  is  best  to 
reengineer  all  business  processes 
concurrently  that  are  sharing  a  migration 
system.  If  this  is  not  feasible,  extreme 
care  must  be  exercised  during  the 
systems  construction  and  integration. 

■  A  new  information  systems  project  can 
be  authorized  that  will  build  information 
systems  support  for  a  business  process 
from  the  ground  up.  If  this  path  is 
selected,  it  is  best  to  assess  the 
possibility  of  the  new  system  replacing 
one  or  more  legacy  and/or  migration 
systems.  The  danger  here  is  that  the 
project  will  become  too  complex  which 
implies  much  more  risk  than  may  be 
acceptable. 

The  problem  of  systems  integration  can  be 
simply  defined.  An  organization  has  an  existing 
technical  or  information  systems  infrastructure.  It 
also  has  a  model  which  presents  a  vision  of  how  the 
enterprise  desires  to  function.  All  new  information 
systems  must  be  made  part  of  this  technical 
infrastructure  while  satisfying  enterprise  model 
objectives. 

There  are  three  ways  this  can  be  done: 

■  The  new  information  system  can  be 
installed  but  not  connected  or  associated 
with  existing  information  systems.  This 
means  that  the  objectives  of 
interoperability  and  data  sharing  cannot 
be  met.  This  is,  in  fact,  how  most  large 


organizations  have  added  new  systems  to 
their  inventory  over  the  last  few  decades. 

■  The  new  information  can  be  installed  and 
interfaces  can  be  built,  as  necessary,  to 
other  existing  information  systems.  This 
often  provides  some  measure  of  cross¬ 
function  interoperability  and  data 
sharing,  but  not  at  the  enterprise  level. 
Over  time,  this  arrangement  usually 
degrades  as  interfaces  are  added  and 
modified.  Maintenance  costs  rise 
dramatically,  and  it  becomes  difficult  to 
enhance  systems  because  of  the  number 
of  interfaces  that  may  be  affected. 

■  Each  new  information  system  can  be 
integrated  into  the  technical 
infrastructure  such  that  data  created  by 
the  new  system  can  be  shared  with  all 
other  information  systems,  and  the  new 
system’s  functionality  can  be  made 
available  in  all  related  business  or 
functional  areas.  The  term  integration 
means  to  combine  separate  elements  in 
such  a  way  that  they  function  as  a  whole. 
This  is,  of  course,  the  preferred  method, 
but  it  often  delays  information  systems 
deployment  while  the  integration 
activities  are  being  performed.  If  the 
new  information  system  is  already 
behind  schedule  by  the  time  it  gets  to  the 
integration  step,  pressures  to  forego 
integration  can  be  severe. 

Technical  staff  can  often  make  significant 
improvements  in  the  technical  infrastructure, 
especially  in  the  area  of  cost,  independently  of 
either  process  or  organization.  For  instance,  if  an 
enterprise  has  five  separate  accounting  systems 
supporting  five  separate  accounting  organizations,  it 
is  likely  that  technical  staff  can  combine  these  into 
one  accounting  system  that  supports  all  five 
organizations.  This  can  often  be  accomplished 
apart  from  involving  any  functional  staff.  Of 
course,  there  will  be  little  if  any  improvements  seen 
at  the  business  process  level,  but  significant  cost 
savings  may  be  realized  by  the  technical 
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organization.  In  other  words,  designating  migration 
systems  and  decommissioning  legacy  systems  can 
be  done  apart  from  business  process  reengineering. 
When  it  can  be  done,  it  should  be  done. 

In  summary,  an  enterprise-wide  objective  is  to 
modernize  the  DoD  information  infrastructure  to 
support  the  objectives  of  the  DoD  Enterprise  Model 
as  expressed  in  information  systems  support 
requirements  for  improved  or  reengineered  business 
processes.  The  most  effective  way  to  do  this  is  to 
build  information  systems  that  support  business 
requirements  then  integrate  them  into  the  existing 
information  or  technical  infrastructure.  Over  time, 
the  technical  infrastructure  will  migrate  toward  an 
enterprise-wide  objective  of  open  systems,  shared 
data,  and  interoperability. 

The  Assistant  Secretary  of  Defense  for 
Command,  Control,  and  Intelligence  has  established 
12  objectives  for  moving  the  DoD  toward  an 
integrated  enterprise  state.  The  accomplishment  of 
all  of  these  objectives  depends,  in  least  in  part,  on 
constructing  sound  cross-functional  information 
systems  based  on  end-to-end  process  management 
which  can  be  integrated  into  an  enterprise-wide 
technical  infrastructure.  Please  refer  to  CIMfor  the 
21st  Century:  a  DoD  Strategic  Plan  for  more 
detailed  information  about  these  objectives. 

■  Aggressively  pursue  process  changes  in 
DoD  operations  that  will  yield  improved 
efficiency  and  effectiveness 

■  Implement  reengineering  on  a  sustaining 
basis  so  that  it  is  responsive  to  the 
guidance  and  priorities  of  the 
Department’s  leadership 

■  Derive  standard  definitions  of  data  on  an 
aggressive  schedule 

■  Establish  strong  management  of  data 
quality,  including  data  availability, 
integrity,  accuracy,  and  security 

■  Eliminate  unnecessary  duplicate  systems 
and  migrate  toward  a  common  baseline 
of  information  systems 


■  Implement  enhanced  information 
systems  that  incorporate  reengineering 
results  as  well  as  standards  based 
technology 

■  Implement  a  computer  and 
communications  infrastructure  that  is 
transparent  to  the  application  software 
residing  on  it 

■  Establish  technical  policies  and  standards 
based  on  open  system  architecture  to 
guide  implementation  of  the 
infrastructure 

■  Integrate  technical  programs,  particularly 
cross-functionally,  so  that  barriers  such 
as  data  sharing,  transfer  and 
interoperability  are  identified  and 
removed 

■  Integrate  end-to-end  functional  processes 
to  achieve  greater  effectiveness  and 
efficiency 

■  Ensure  that  the  corporate-wide 
information  management  structures  are 
put  in  place  and  can  support  the  DoD’s 
information  needs  for  the  21st  century 

■  Establish  CIM  policy  to  guide  CIM 
implementation  by  communicating  and 
clarifying  goals,  objectives,  methods,  and 
procedures. 

Tapscott  and  Caston  offer  these  objectives  for 
achieving  enterprise  integration.  As  can  be  seen, 
the  need  for  enterprise  integration  in  DoD  and  the 
objectives  needed  to  achieve  this  are  consistent  with 
efforts  in  the  private  sector 

■  Establishing  new  service  levels  for 
increased  customer  satisfaction  and 
loyalty.  Public  sector  enterprises  may 
want  to  substitute  “support"  for 
“loyalty.  ” 
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■  Creating  new  business  opportunities 
through  the  extension  of  existing  product 
and  service  offerings  or  the  development 
of  new  ones 

■  Streamlining  organizational  procedures 
and  achieving  of  synergy  through  logical 
applications  integration. 

■  Lowering  unit  costs  of  computer  and 
communication  systems  through  the 
sharing  of  common  architectures  and 
delivery  systems 

■  Leveraging  experience  from  all  areas  of 
systems  applications  to  address  common 
needs 

■  Developing  an  infrastructure  to  support 
increased  decentralization  and  autonomy 

■  Establishing  a  basis  for  quickly  reacting 
to  changing  customer  demands  and 
business  developments. 

The  following  tasks  are  performed  in  the 
design  systems  integration  plan: 

■  Design  Platform  Integration  Plan 

■  Design  Data  Base  Integration  Plan 

■  Design  Application  Systems  Integration 
Plan 

■  Review  IS  for  Conformity  with  DoD 
Enterprise  Model 

■  Identify  and  Resolve  Cross-Functional 
Process  Issues 

■  Identify  and  Resolve  Interoperability 
Issues  and  Concerns 

■  Develop  Revised  (TO-BE)  Architectures 

■  Update  Defense  Data  Repository  System 

■  Develop  Transition/Migration  Plan 

■  Conduct  Pre-installation  and  Deployment 
Conference 

8.5.1  Design  Platform  Integration  Plan.  The 
most  basic  form  of  integration  is  performed  at  the 
hardware  platform  or  machine  level.  Hardware  and 
communications  equipment  represent  an  expensive 
resource  with  an  ever  decreasing  useful  life  cycle. 


It  is  imperative  to  achieve  minimum  unplanned 
redundancy  and  maximum  utilization  of  this  vital 
resource.  This  can  be  accomplished  through  the  use 
of  effective  planning,  efficient  design,  standard 
architectures,  and  strict  configuration  control. 
Through  the  acceptance  of  international  standards, 
and  the  trend  toward  multi-vendor  environments, 
we  are  fast  approaching  an  era  where  data  systems 
and  applications  will  be  fully  independent  of 
hardware  devices.  This  will  make  it  possible  to 
support  a  wide  variety  of  applications  within  the 
same  physical  plant. 

Studies  have  shown  that  most  computer  and 
communications  equipment  is  underutilized  by 
functional  organizations  which  means  that 
investments  in  increased  productivity  are  not 
returning  the  hoped  for  benefits.  There  is  a  growing 
trend  to  out-source  computer  facility  management 
and  operations  to  service  bureaus  who  make  it  a 
business  to  fully  utilize  their  resources. 

Functional  management  who  directly  or 
indirectly  fund  technological  investments  should 
make  every  effort  to  assure  an  acceptable  return  on 
investment  for  computer  and  communications 
platforms.  One  way  to  do  this  is  to  insist  on  the  use 
of  international  standards,  open  systems,  and  off- 
the-shelf  products  whenever  and  wherever  possible. 
The  use  of  specialized  platforms  is  only  warranted 
where  an  overwhelming  benefit  can  be  obtained. 
The  platform  plan  provides  a  vehicle  for  ensuring 
responsible  acquisition  and  wise  use  of  platform 
resources. 

8.5.2  Design  Data  Base  Integration  Plan.  Data  is 
the  life  blood  of  an  organization  and  enterprise 
integration  can  only  be  achieved  to  the  extent  that 
the  organization  can  create  and  sustain  enterprise¬ 
wide  data  sharing.  Data  administrators,  data  base 
administrators,  and  data  base  technicians  are 
charged  with  the  responsibility  to  support  specific 
application  data  requirements  within  the  context  of 
enterprise-wide  data  sharing.  Modem  data  base 
technology  and  the  acceptance  and  use  of  industry 
standards  for  data  base  management  have  solved 
most  of  the  technical  problems  associated  with 
creating  and  maintaining  shared  data  systems.  If 
there  are  any  weaknesses,  they  are  in  the  data 
administration  area. 
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Functional  managers  can  facilitate  the 
development  of  the  shared  data  resource  by 
supporting  data  standardization,  building  solid  data 
models,  working  cooperatively  with  data 
administration,  and  forging  strong  cross-functional 
(process-based)  agreements  with  their  peers. 
Object-oriented  data  base  technology  holds  the  most 
promise  for  facilitating  the  construction  of  shared 
data  bases.  Functional  managers  should  support  the 
transition  to  this  technology. 

Functional  managers  should  also  deal 
aggressively  with  data  ownership  issues.  To  the 
extent  that  data  can  be  owned,  it  is  owned  by  the 
organizational  unit  that  creates  it.  But,  one  of  the 
rules  of  data  management  is  that  data  should  only 
be  created  once  at  the  logical  point  of  entry  into  the 
enterprise.  This  means  that  unless  an  organizational 
unit  intends  to  use  only  the  data  it  itself  creates,  it 
must  have  access  to  data  owned  by  other 
organizational  units  in  order  to  perform  useful 
work.  This  implies  a  responsibility  to  share  data 
freely  if  the  mission,  goal,  and  objectives  of  the 
enterprise  are  to  be  met.  Once  this  concept  is  fully 
supported  by  all  functional  management,  the  road  to 
building  enterprise- wide  shared  data  bases  is  greatly 
facilitated. 

8.5.3  Design  Application  Systems  Integration 
Plan.  Integration  at  the  application  system  level  is 
enormously  difficult  to  achieve  apart  from 
reengineering  the  processes  and  functional 
organizations  involved  as  part  of  the  integration 
effort.  This  is  especially  trae  when  trying  to 
integrate  a  new  application  into  one  or  more 
existing  application  systems  that  have  a  history  of 
maintenance  and  enhancement  actions  over  a  long 
period  of  time.  Except  in  the  most  disciplined 
technical  organizations,  documentation  for  existing 
systems  is  missing  or  suspect,  patches  to  software 
code  may  be  difficult  to  understand,  and  the  original 
programmers  may  no  longer  be  with  the 
organization. 

As  anyone  with  a  programming  background 
can  attest,  a  change  to  a  single  line  of  software  code 
can  cause  unexpected  and  difficult  to  resolve  errors. 


Also,  every  time  a  line  of  code  is  changed,  it  is 
prudent  to  retest  all  elements  of  the  information 
system  that  may  be  affected  by  the  change — a  time- 
consuming  and  costly  process. 

As  object-oriented  programming  becomes 
established,  effective  software  reuse  libraries  come 
into  use,  software  engineering  practices  are 
enforced,  and  enterprise- wide  data  bases  are  in 
operation;  the  problem  of  integration  at  the 
application  level  will  be  facilitated.  Maintaining 
current  information  and  application  architectures 
also  facilitates  application  system  integration. 

As  noted  earlier  in  the  methodology,  technical 
organizations  can  often  consolidate  two  or  more 
existing  (legacy)  application  systems  into  a 
modernized  migration  system  apart  from  functional 
organizational  involvement.  For  critical  production 
systems,  this  must  be  done  following  strict  project 
management  precepts  so  as  not  to  adversely  impact 
the  availability  of  legacy  systems  to  serve 
functional  needs. 

Functional  managers  should  make  it  a  point  to 
be  aware  of  all  changes  (including  migration 
systems  efforts)  planned  for  information  systems 
that  are  in  place  to  support  their  business  processes. 
They  should  also  insist  on  a  rigorous  test  program 
as  part  of  change  or  improvement  efforts  to 
minimize  the  possibility  of  disruption  to  their 
business  operations. 

8.5.4  Review  Information  Systems  for 
Conformity  with  DoD  Enterprise  Model.  The 

DoD  Enterprise  Model  is  meant  to  be  an  integration 
document.  As  such,  it  should  be  referenced  before, 
during,  and  after  integration  efforts  at  any  systems 
component  level.  All  changes  and  enhancements  to 
the  information  infrastructure  should  advance  the 
enterprise  toward  achieving  enterprise  model  and 
strategic  planning  goals  and  objectives. 

The  DoD  Enterprise  model  is  a  representation 
of  the  activities  and  data  of  the  entire  Department 
currently  needed  to  accomplish  the  defense  mission, 
from  planning  to  acquisition  and  logistics  support  to 
warfighting.  The  model  includes  all  the  top  level 
processes  and  standard  data  interfaces  for  every 
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DoD  major  mission  and  function,  it  provides  a 
common  basis  for  enterprise-wide  coordination  and 
collaboration. 

As  senior  managers  plan  innovations  and 
improvements  to  their  activities,  they  will  use  the 
model  to  identify  specific  points  where  they  interact 
with  other  parts  of  the  Department.  These 
interactions  can  be  any  or  all  of  the  current  or 
proposed  platforms,  data  representations,  or 
application  systems.  This  knowledge  will  enable 
them  to  plan  changes  in  concert  with  other 
managers  to  ensure  that  they: 

■  Manage  strategic  changes  from  a  DoD- 
wide  perspective  by  measuring  the 
impacts  across  the  Department  and 
selecting  globally  optimal  solutions 

■  Obtain  quality,  affordable  products  and 
services  (platforms,  data  bases, 
application  software),  when  and  where 
needed  (geo-technical  architectures)  to 
perform  their  individual  mission 

■  Share  common  processes,  data,  and 
support  mechanisms,  rather  than 
duplicate  them. 

Once  mission  and  function  activity  and  data 
models  are  developed  and  approved,  they  become  a 
part  of  the  DoD  Enterprise  Model.  The  entire 
Department  has  access  to  these  models.  They 
provide  a  baseline  for  specifying  functional  and 
systems  interfaces,  identifying  and  evaluating  the 
impacts  of  the  changes  to  one  mission  or  function 
on  other  missions  and  functions,  and  developing 
improved  processes,  platforms,  data  structures,  and 
application  systems  that  will  lead  to  greater 
integration,  interoperability,  flexibility, 
effectiveness,  and  efficiency  in  the  Department  of 
Defense. 

Thus,  the  DoD  Enterprise  Model  provides  a 
standard  reference  for  helping  to  ensure  that  DoD 
goals  and  objectives  are  achieved  with  respect  to 
functional  and  technical  activities. 


8.5.5  Identify  and  Resolve  Cross<Functional 
Process  Issues.  The  time  to  recognize  and  deal 
with  cross-functional  problems,  issues, 
misunderstandings,  and  disagreements  is  prior  to 
systems  installation  and  deployment.  Once  the 
installation  period  begins,  solving  cross-functional 
problems  is  magnified  by  the  effort  to  complete 
installation  and  bring  a  new  system  on-line.  Prior  to 
installation,  only  the  technical  staff  and  a  few 
functional  people  are  involved.  After  the 
installation  period  begins,  hundreds  if  not  thousands 
of  people  are  involved  in  the  new  system. 

Issues  are  generally  the  result  of 
misunderstandings  and/or  ineffective 
communications  at  one  or  more  stages  of  the 
project.  They  also  surface  when  some  unplanned 
event  or  situation  impacts  the  project,  especially  the 
scope  or  quality  components  of  the  project.  Issues 
are  difficult  to  anticipate  unless  extensive  and  open 
communications  take  place  in  the  early  stages  of  a 
project  with  all  project  principals  and  concerned 
parties. 

The  following  procedure  should  be  used  to 
resolve  issues  associated  with  the  impending  new 
system: 

■  Describe  the  issue  as  fully  and 
completely  as  possible 

■  Identity  all  project  principals  and 
concerned  parties  that  are  impacted  or 
affected  by  the  issue.  Identify  technical 
or  professional  experts  who  can  be  asked 
to  help  resolve  issues 

■  Gather  all  data  related  to  the  issue 
including  assumptions,  constraints, 
possible  alternative  approaches,  and 
associated  risk  data 

■  Assess  the  impact  of  each  issue  on 
project  success 

■  Schedule  and  conduct  a  series  of 
meetings  with  involved  parties.  Each 
meeting  should  have  a  clearly  defined 
objective  staged  as  follows: 
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—  Fact  gathering  to  develop  all  sides 
of  the  issue 

—  Presentation  of  alternative 
resolutions 

—  Discussion  of  potential  outcomes 
from  each  alternative 
—  Selection  of  an  alternative 

—  Assignment  of  roles, 

responsibilities,  and  action  items 

■  As  necessary,  issue  appropriate  change 
orders 

■  Track  each  issue  as  a  suspense  item  until 
all  action  items  have  been  completed 

■  Close  out  issue,  update  documentation  as 
needed,  and  notify  all  personnel  affected 
by  implementing  the  issue  resolution. 

8.5.6  Identify  and  Resolve  Interoperability 
Issues  and  Concerns.  In  contrast  to  the  cross¬ 
functional  issues  discussed  above,  there  are  often 
technical  issues  that  are  related  more  to 
infrastructure  issues  than  to  functional  or 
operational  issues.  These  come  about  because  there 
are  often  several  technical  approaches  possible  to 
achieve  desired  outcomes.  Often  technical  issues 
are  matters  of  preference  based  on  the  background 
and  experience  of  the  involved  parties.  To  head  off 
or  resolve  such  issues,  strong  project  leadership  is 
called  for. 

Usually,  technical  issues  can  be  resolved  by 
referring  to  the  enterprise  model,  standard 
architectures,  and  configuration  management 
guidelines.  In  all  cases,  the  overarching  objectives 
of  providing  an  enterprise-wide  technical 
infrastructure  should  take  precedent  over  technical 
solutions  weighted  to  a  particular  functional  area  or 
technical  problem.  In  the  fury  of  trying  to 
implement  systems,  there  are  pressures  to  make 
expedient  compromises  in  order  not  to  delay 
projects.  Such  compromises  usually  end  up  causing 
problems  downstream  that  are  considerably  more 
difficult  and  expensive  to  solve.  Project  managers 
and  leaders  should  be  aware  of  this  axiom:  There  is 
never  time  or  money  to  do  it  right  the  first  time,  but 
there  is  always  time  and  money  to  do  it  over. 


8.5.7  Develop  Revised  (TO-BE)  Architectures. 

Once  the  information  systems  project  is 
approaching  the  installation  and  deployment  stage, 
and  after  all  critical  functional  and  technical  issues 
have  been  addressed  and  resolved;  all  technical 
models,  standard  architectures  and  configuration, 
and  repository  records  should  be  provisionally 
updated  based  on  the  new  system.  This  can  serve  as 
a  final  audit  of  the  impact  of  the  new  system  on  the 
technical  infrastructure.  If  the  TO-BE  architectures 
appear  to  be  in  conformance  with  DoD  mission, 
policy,  goals,  and  objectives,  the  project  should 
move  forward.  If  conflicts  or  anomalies  are 
detected,  they  should  be  addressed  and  resolved 
before  the  project  moves  forward. 

8.5.8  Update  Defense  Data  Repository  System. 
The  finaJ  technical  task  prior  to  installation  and 
deployment  is  to  update  all  technical  documentation 
as  required  especidly  that  documentation  residing 
in  the  Defense  Data  Repository  System  (DDRS).  It 
is  vital  that  installation  and  deployment  teams  have 
accurate  and  up-to-date  documentation  to  guide 
them  through  the  installation  period.  Because  the 
repository  is  one  of  the  tools  to  facilitate  the 
Department’s  objectives  of  achieving 
interoperability,  other  projects  need  timely  access  to 
information  about  all  new  systems. 

8.5.9  Develop  IVansitionyMigration  Plan.  The 

transition/migration  plan  may  be  considered  to  be 
the  input  to  the  project  execution  phase  described  in 
section  9  of  this  guidebook.  It  should  contain  all  of 
the  technical  data  needed  by  the  installation/ 
deployment  project  manager  to  develop  the  project 
execution  plan.  Please  note  that  there  are  several 
other  documents  that  are  also  needed  to  construct 
the  project  execution  plan,  but  this  one  is  primarily 
technical  in  nature. 

The  complexity  of  specific  Automated 
Information  Systems  (AIS)  integration  efforts  will 
differ  greatly  firom  one  integration  project  to 
another.  An  integration  effort  may  be  as  simple  as 
authorizing  users  of  existing  or  legacy  systems  to 
begin  preparations  for  moving  to  the  migration 
system  or  new  information  system.  Or  it  may  entail 
a  significant  development  effort  to  enhance  the 
selected  migration  application  to  provide  the 
processing  capabilities  of  all  existing  legacy 
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applications.  It  may  even  require  the  move  to  an 
entirely  new  AIS  for  which  there  is  no  migration 
system  established. 

The  transition  plan  needs  to  address  security, 
privacy,  integrity,  accessibility,  and  availability  with 
respect  to  technical  facilities  and  controls. 
Integrating  AIS  often  raises  technical  issues 
concerning  how  two  or  more  functional  areas  can 
interact  with  a  single  application  system  and/or 
shared  data  base.  These  concerns  may  not  be 
evident  while  constructing  an  AIS  for  a  single 
functional  area,  but  become  significant  issues 
during  AIS  integration. 

The  following  issues  should  be  addressed  in 
the  transition/migration  plan.  With  these  issues 
defined  and  resolved,  it  is  possible  for  the  project  to 
proceed  to  the  installation  and  deployment  phase 
with  a  higher  level  of  confidence  in  its  success. 

■  Application  Integration: 

—  Are  the  functional  capabilities  of 
the  application  well-documented 

—  Are  the  functional  requirements  of 
involved  legacy  system  users 
accounted  for  in  the  transition  to 
the  migration  or  target  system 

—  Are  all  required  changes, 

modifications,  and  enhancements  in 
place  so  that  operations  will  not  be 
disrupted  during  changeover? 

■  Data  Integration: 

—  Are  all  requirements  for  data 
integration  accounted  for 

—  Are  utilities  in  place  to  effect  the 
conversion  of  legacy  system  data  to 
the  migration  or  target  system 

—  Are  arrangements  in  place  to  scrub 
or  reformat  legacy  data  as 
necessary  to  support  the 
requirements  of  the  new  system 


—  Are  criteria  in  place  to  validate  or 
audit  converted  data,  and  is  a 
program  in  place  to  reconstruct 
invalid  data? 

■  Platform  Integration: 

—  Are  arrangements  in  place  to 
acquire  or  relocate  all  needed 
hardware  components  including 
communications  facilities 

—  Have  capacity  calculations  been 
made  to  ensure  that  hardware 
facilities  can  support  expected 
storage  and  processing  loads 

—  Are  arrangements  in  place  to 

acquire,  upgrade,  or  create  needed 
systems  software  components 
including  utilities 

—  Have  all  hardware  and  systems 
software  support  and  maintenance 
requirements  been  documented? 

■  Security,  Privacy,  and  Integrity: 

—  Are  specifications  in  place  to 
control  access  to  data  and 
applications  in  compliance  with  all 
applicable  security  and  privacy 
laws,  regulations,  and  directives 

—  Are  specifications  in  place  to 
ensure  systems,  data,  and 
application  integrity  with  respect  to 
backup,  recovery,  and  restore 
operations — especially  in 
distributed  applications  and  data 
environments 

—  Have  arrangements  been  put  in 

place  for  secure  storage  and  backup 
processing  sites? 
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■  Acquisition  and  Procurement: 

—  Is  the  status  and  schedule  related  to 
hardware,  software,  and  services 
procurement  consistent  with 
planned  installation  and 
deployment  requirements  and 
schedules 

—  Has  a  backup  plan  been  established 
to  secure  needed  resources  on  a 
temporary  basis  until  procured 
items  have  been  delivered? 

■  Pre-installation  Activities : 

—  Have  arrangements  been  made  to 
populate  all  data  bases  with 
production  data 

—  Are  arrangements  in  place  to 
provide  for  parallel  operations 
during  the  final  testing  phases  of 
the  project 

—  Are  arrangements  in  place  to 

provide  for  an  orderly  transition  to 
the  new  system  following  parallel 
testing  and  completion  of  all 
system  acceptance  tests 

—  Are  hardware,  software,  and 
support  resources  adequate  to 
handle  both  operational  systems 
and  testing,  parallel,  and  cut-over 
requirements  for  the  new  system? 

8.5.10  Conduct  Pre-installation  and  Deployment 
Conference.  The  final  task  in  this  step  is  to 
schedule  and  conduct  a  pre-installation  and 
deployment  conference.  The  purpose  of  this 
conference  is  to  review  the  status  of  all  activities 
and  functions  that  must  be  completed  prior  to 
systems  installation  and  deployment.  All  process, 
organizational,  and  technical  plans,  specifications, 
designs,  and  developments  are  reviewed  for 


completeness  and  accuracy  with  respect  to  ensuring 
a  successful  installation. 

The  process  improvement  project  to-date  has 
generated  a  library  of  documents,  models, 
spreadsheets,  and  narratives  related  to  all  aspects  of 
the  project.  Some  are  manual,  and  some  are 
automated.  At  this  point,  all  of  the  components  for 
the  new  system  are  in  place  including  policies  and 
procedures,  data  bases,  application  code,  training 
programs,  organizational  change  orders;  but  no 
actual  changes  to  the  environment  have  been  made. 
It  is  important  to  realize  that  functional  mangers, 
users,  and  customers  have  not  yet  seen  any 
improvements  or  enhancements.  Whether  they  will 
or  not  has  a  lot  to  do  with  the  success  of  this 
conference. 

All  involved  functional  and  technical  elements 
should  participate  in  this  conference  which  is 
chaired  by  the  designated  project  manager  for 
installation  and  deployment.  During  this 
conference,  the  project  manager  is  expected  to 
satisfy  him/herself  that  everything  is  in  place  to 
proceed  to  the  next  phase  of  the  methodology. 

It  is  likely  that  the  pre-installation  conference 
will  take  from  two  to  five  days  depending  on  the 
extent  and  complexity  of  the  project.  The  amount 
of  documentation  that  has  to  be  reviewed,  the 
quality  of  this  documentation,  and  the  way  it  is 
organized  will  also  determine  the  length  of  the 
conference.  At  the  conclusion  of  the  conference, 
the  responsibility  for  the  continuation  and  success 
of  the  project  shifts  to  the  project  manager. 

This  completes  the  enterprise  engineering 
phase  of  the  framework  methodology.  During  this 
phase,  one  or  more  information  systems  were 
constructed  according  to  the  requirements  set  forth 
in  the  FEA  and  its  supporting  documents.  Provision 
was  made  to  integrate  the  new  information  systems 
into  the  technical  infrastructure  in  accordance  with 
enterprise-wide  models,  architectures,  and 
configurations.  Preparations  were  made  to 
transition  to  the  next  phase  of  the  methodology — 
project  execution.  During  the  project  execution 
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phase,  all  elements  of  process  improvement 
described  in  the  framework  methodology  will  be 
brought  together  to  effect  a  successful  installation 
and  deployment  of  the  newly  reengineered  process, 
its  supporting  information  systems,  and  necessary 
organizational  and  functional  changes. 
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SECTION  9.  PHASE  4:  PROJECT  EXECUTION 


During  the  entire  period  of  the  process 
improvement  project  to  this  point,  the  organization 
has  not  benefited  in  any  substantial  way  from  the 
efforts  of  the  improvement  team.  The  business 
process  has  not  changed  except  perhaps  for  some 
quick  improvements  or  streamlining  actions.  The 
existing  information  systems  are  still  in  place.  The 
organization  is  likely  the  same  as  it  was  at  the 
beginning  of  the  project. 

By  now  the  process  team  has  designed  the  TO- 
BE  process  including  activity  and  data  models.  The 
information  system  that  will  support  the  new 
process  has  been  constructed  and  tested.  The 
organizational  change  management  plan  has  been 
developed  and  approved  which  means  the  new 
management  structure,  work  methods,  and  work 
flows  have  been  established.  Documentation, 
including  new  or  revised  policies,  directives, 
procedures,  and  forms  are  designed  and  ready  to  be 
deployed.  Training  systems  are  in  place  and  tested, 
and  the  support  structure  for  the  reengineered 
process  and  its  underlying  information  systems  has 
been  completed  and  tested  at  the  pilot  site. 

The  time  is  at  hand  to  install  and  deploy  the 
improved  process  throughout  the  organization.  The 
entire  installation  and  deployment  process  must  be 
exceedingly  well  planned  and  flawlessly  executed. 
Any  critical  problems  at  this  stage  can  disrupt 
business  operations,  confuse  and  frustrate 
stakeholders,  and  result  in  irreparable  harm  to  the 
enterprise  as  a  whole.  Most  reengineering  projects 
that  ultimately  fail,  do  so  because  of  poor  project 
planning  and  execution. 

Once  the  new  process  is  deployed  along  with  its 
information  systems  and  organizational  changes,  the 
project  enters  the  operation  and  maintenance  stage. 
During  this  stage,  performance  is  continually 
monitored  to  ensure  that  the  process  is  meeting  all 
business  objectives  on  a  continuing  basis. 
Maintenance  activities  are  performed  as  a  result  of 
operational  feedback,  problems,  and  the  emergence 
of  exceptional  conditions  that  were  not  considered 
during  the  earlier  phases  of  the  project.  Training 
programs  are  conducted  as  necessary  to  train  new 


personnel  including  new  customers  and  partners. 
The  operation  and  maintenance  stage  continues  for 
as  long  as  the  process  is  required  to  support 
enterprise  mission,  goals  and  objectives. 

Continuous  process  improvement  (CPI), 
which  is  another  term  for  total  quality  management, 
should  be  institutionalized  and  practiced  to  continue 
the  progress  made  during  process  reengineering. 
Few  business  situations  are  static  so  there  are 
always  opportunities  to  make  minor  improvements 
that  over  time  result  in  major  benefits.  Also,  it  is 
unlikely  that  the  formal  process  improvement 
project  was  able  to  foresee  or  consider  all  operating 
conditions.  Finally,  CPI  as  an  institution  keeps 
process  employees  focused  on  the  customer  and 
meeting  business  objectives  as  well  as  interested  in 
their  work  assignments.  New  products,  services, 
and  methods  typically  result  when  organizations 
practice  CPI.  One  consumer  products  company  in 
Ohio  typically  gets  4000  new  ideas  each  year  from 
their  employees  related  to  building  the  business  and 
providing  customers  with  new  and  interesting 
products. 

The  project  execution  phase  of  the  Framework 
methodology  is  supported,  in  part,  with  the 
following  resources: 

■  F/MPI  Organizational  Change 
Management  IVitorial 

■  F/MPI  Case  Study  in  Change 
Management 

■  Project  Manager’s  Handbook  written  by 
Robert  J.  Davis 

■  The  DoD  Enterprise  Model  White  Paper 

■  DoD  Enterprise  Integration: 
Implementing  Strategy 

The  techniques  (see  Section  10)  most  useful  in  this 
phase  include  the  following: 

■  Affinity  diagramming 

■  Relationship  diagramming 

■  Force  field  analysis 

■  Process  Decision  Program  Chart 

■  Tree  Diagrams 
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■  Program  Evaluation  and  Review 
Technique  (PERT) 

■  Gantt  charts 

■  Cause  and  Effect  charts 


9.1  Step  21:  Develop  Installation/Deployment 

Project  Management  Plan 

The  installation  and  deployment  plan  is 
critical  because  this  is  the  stage  of  the  improvement 
project  that  involves  the  most  people — many  who 
are  being  introduced  to  the  improved  process  and 
new  information  systems  for  the  first  time. 
Deployment  generally  covers  a  lot  of  geography  up 
to  and  including  the  entire  world.  Because  many  of 
the  elements  of  the  project  are  coming  together  for 
the  first  time,  it  is  also  the  most  complex  part  of  the 
project  and  has  the  highest  risk  of  failure.  Every 
element  of  project  execution  is  time  critical, 
resource  consumptive,  and  costly  to  redo  in  the  case 
of  serious  problems. 

For  these  reasons,  it  is  important  to  construct  a 
project  plan  that  spans  the  entire  installation  and 
deployment  phase.  Essentially,  a  project  plan  lays 
out  the  installation  and  deployment  phase  as  a  series 
of  interrelated  tasks.  Some  of  these  tasks  are 
performed  sequentially  while  others  can  be 
performed  in  parallel.  Each  task  will  have  a 
deliverable,  start  date,  duration,  cost,  and  resource 
assignment.  In  addition  to  tasks,  there  will  be 
milestones  indicated  that  provide  checkpoints  to 
gauge  project  status.  The  essence  of  project 
management  is  to  break  down  a  large  project  into  a 
series  of  tasks  that  can  be  closely  managed.  If  each 
task  completes  on  time,  within  budget,  and  at  the 
expected  quality  level,  then  the  project  will 
complete  on  time,  within  budget,  and  at  the 
expected  quality  level. 

Projects  can  easily  be  laid  out  using 
commercial  off-the-shelf  project  management 
software  that  will  run  on  any  personal  computer. 

The  software  allows  the  project  manager  to 
construct  a  PERT  chart  that  provides  a  graphical 
representation  of  all  tasks  in  the  project  and  the  way 
tasks  are  related  to  each  other.  The  series  of  tasks 
that  make  up  the  critical  path  are  those  that  if  not 
completed  on  time  will  delay  completion  of  the 


project.  Other  tasks  are  said  to  have  slack  time 
which  means  there  is  some  allowance  for  slippage 
without  jeopardizing  the  project  completion  date. 

PERT  is  an  acronym  for  Project  Evaluation 
and  Reporting  Technique.  PERT  was  developed  by 
the  U.S.  Navy  during  World  War''!!  to  facilitate 
submarine  construction.  Project  manager  software 
provides  a  variety  of  report  formats  that  can  be  used 
to  control  project  progress.  Project  management 
software  is  especially  helpful  when  elements  of  the 
project  are  dispersed  geographically.  The  PERT 
chart  and  other  related  reports  can  be  maintained  on 
a  network  of  computers  so  that  all  project 
participants  can  access  the  latest  project 
information. 

Important  as  the  project  plan  is  and  the 
software  that  contains  it,  nothing  is  more  important 
that  project  leadership.  The  following  eight 
principles  are  proven  for  effective  project 
leadership. 

1 .  Own  the  project  but  share  the  success.  A 
project  manager  must  be  totally  committed  to 
the  success  of  the  project.  When  things  are 
going  well,  the  project  manager  must  publicly 
credit  others,  when  things  are  not  going  will, 
the  project  manager  must  assume  the 
responsibility  and  increase  efforts  to  get  the 
project  back  on  track. 

■  Acknowledge  in  meetings  and  status 
reports  the  contributions  that  others  make 
to  task  and  milestone  completion. 

■  Do  not  publicly  blame  others  for  project 
problems.  Accept  the  responsibility  then 
work  directly  with  others  to  correct 
project  discrepancies. 

■  Understand  and  respect  the  fact  that  there 
is  a  high  ego  involvement  in  project 
work:  yours  and  everyone  else’s.  Avoid 
letting  egos  get  in  the  way  of  project 
performance. 

2.  Delegate  responsibility  but  maintain  control. 

A  project  manager  must  delegate 
responsibility  for  task  completion  and  apply 
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the  principle  of  inspect  what  you  expect. 
Everyone  concerned  with  the  project  must 
understand  and  accept  their  role  and  the 
impact  of  their  assignments  on  the  project  as  a 
whole. 

■  Ensure  that  project  plans  clearly 
designate  the  responsibility  for  task 
completion. 

■  Size  tasks  (duration  and  cost)  so  that  they 
represent  a  reasonable  but  visible  level  of 
eff^ort.  If  tasks  are  too  small,  they  will 
not  get  enough  attention  and  may  be 
“forgotten.”  If  they  are  too  large,  they 
may  overwhelm  the  responsible  person. 

■  Inspect  task  progress  on  a  weekly  basis. 
More  frequent  attention  leads  to  micro- 
management,  less  frequent  attention  risks 
schedule  and  cost  overruns. 

3.  Provide  the  project  vision  but  manage  the  task 
at  hand.  The  project  manager  must  ensure 
that  all  project  participants  understand  the 
mission  and  purpose  of  the  project  in  the 
context  of  process  and  information  systems. 

At  the  same  time,  projects  are  completed 
successfully  by  completing  each  individual 
task  successfully. 

■  Ensure  that  each  person  responsible  for  a 
task  understands  the  relationship  of  that 
task  to  succeeding  tasks  and  to  the 
project  as  a  whole.  Use  the  PERT  chart 
as  a  motivation  tool. 

■  Get  a  reputation  for  insisting  that  each 
task  be  completed  on  time  and  within 
budget  and  at  an  acceptable  quality  level. 
Focus  on  tasks  as  soon  as  they  begin  to 
deviate  from  plan. 

■  Manage  tasks  on  the  critical  path  at  a 
higher  level  than  other  tasks.  Make  sure 
that  responsible  persons  know  whether 
their  task  is  on  the  critical  path. 

4.  Expect  the  unexpected  but  pursue  perfection. 

A  plan  is  a  navigation  aid.  It  tells  you  when 


you  are  off-course  so  that  you  can  make 
necessary  corrections  before  you  crash  into  the 
mountain.  Poets  may  be  able  to  move 
mountains  but  most  project  managers  can’t. 

It’s  usually  best  to  fly  around  or  over  them. 

■  Ensure  that  your  project  plan  highlights 
high-risk  tasks  so  that  you  can  give 
special  attention  to  them. 

■  Think  through  the  possible  and  probable 
contingencies  associated  with  high-risk 
tasks  so  that  you  have  a  head  start  on 
taking  action  when  problems  and  issues 
occur. 

■  Identify  and  assess  issues  and  problems 
as  soon  as  you  become  aware  of  them. 
Develop  a  mini-plan  to  address  the 
obstacle.  Pursue  the  resolution  of  an 
issue  or  problem  on  a  daily  basis.  This  is 
one  time  that  micro-management  is 
called  for. 

5.  Balance  oral  and  written  communications. 
Oral  communications  are  based  on  trust  and 
automatically  involve  a  higher  level  of  risk 
than  written  communications.  Written 
communications  are  time-consuming  and  can 
create  a  perception  of  distrust  if 
inappropriately  used. 

■  Build  trust  by  using  oral  communications 
on  matters  related  to  non-critical  tasks 
with  individuals  who  have  proven  to  be 
trustworthy. 

■  Confirm  assignments  and  understandings 
in  writing  that  are  related  to  critical  or 
high-risk  tasks. 

■  Commitments  and  actions  related  to 
significant  issues  and  problems  must  be 
tracked  in  writing  to  ensure  clear 
conununications  and  enhance  confidence 
levels  by  those  affected  by  the  issue  or 
problem. 
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6.  Acknowledge  project  complexity  but  champion 
simplicity.  Project  are  by  definition  complex. 
The  purpose  of  using  effective  planning  tools 
is  to  break  a  large  project  into  a  series  of 
relatively  simple  tasks  that  can  be  successfully 
managed.  Any  project  can  be  decomposed 
into  a  series  of  sub-projects,  tasks,  and 
activities.  Use  this  fact  in  developing  your 
concept  of  management.  The  way  you  make  a 
complex  project  simple  is  by  clearly  setting 
expectations,  delegating  authority  and 
responsibility,  and  holding  individuals 
accountable  for  results.  Micro-management 
converts  the  simple  to  the  complex. 

■  Executive  managers  should  be  concerned 
only  with  milestone  performance  and 
issue  resolution. 

■  Project  managers  should  manage  a 
project  as  a  series  of  tasks  by  treating 
each  task  as  a  unit  of  work  with  a  defined 
objective  that  relates  in  some  way  to 
other  tasks. 

■  Task  managers  should  manage  each 
assigned  task  at  the  activity  level  with  an 
emphasis  on  quality  work  performed  on 
time  and  within  budget. 

7.  Balance  project  details  with  overall  project 
objectives.  The  test  of  all  project  related 
actions  is  does  this  action  contribute  to  the 
attainment  of  a  project  objective?  If  not,  why 
are  you  doing  it?  One  of  the  principle  reasons 
project  managers  fail  is  that  they  allow 
themselves  to  become  immersed  in  details  and 
busy  work  that  have  no  apparent  project 
purpose.  While  it  is  hard  to  drain  a  swamp 
when  the  alligators  are  snapping  at  your  heels, 
if  your  objective  is  to  drain  the  swamp,  don’t 
get  sidetracked  by  going  on  an  alligator 
hunting  expedition. 

■  Don’t  over-plan  projects  by  working  at 
too  detailed  a  level.  Combine  or  divide 
tasks  such  that  all  tasks  in  your  project 
are  in  the  range  of  one  week  to  one 
month  in  duration.  Let  the  person 
responsible  for  the  task  manage  the 


performance  of  the  detailed  activities  in 
that  task. 

■  Don’t  micro-manage  task  work.  You 
might  just  as  well  wear  a  big  sign  that 
says:  “I  am  insecure  as  a  project 
manager  so  therefore  I  don’t  trust  you, 
nor  do  I  have  confidence  in  your  ability 
to  complete  assignments.” 

■  Think  through  a  project  when  you  are 
planning  it.  Re-think  it  at  every  major 
milestone.  A  good  swamp  drainer  would 
have  made  sure  that  the  alligator 
situation  was  contained  before  getting 
into  the  water. 

8.  Be  action  oriented  but  maintain  perspective. 
Not  everything  that  happens  on  a  project 
demands  your  immediate  and  concentrated 
attention.  Don’t  set  a  pattern  of  trying  to  solve 
everyone’s  project  problems  because  then, 
everyone  will  come  to  you  with  all  of  their 
problems.  Learn  the  phrase:  “Figure  it  out!” 
This  allows  you  to  conserve  your  time  and 
energy  for  critical  situations  that  do  require 
your  full  attention.  Know  the  dilferences 
between  acting,  reacting,  and  pro-acting. 

■  Act  on  such  project  elements  as 
organizing,  planning,  delegating, 
tracking,  and  controlling  the  project  at 
the  task  level,  not  the  activity  or  detail 
level. 

■  Re-act  on  issues  and  problems  associated 
with  critical  or  high-risk  tasks 
immediately. 

■  Pro-act  on  coordination  and 
communications  so  that  you  can  stay 
ahead  of  the  project. 

The  following  tasks  are  performed  in  the 
develop  installation/deployment  project 
management  plan: 

■  Review  Approved  lYoject-related 
Documents 

■  Construct  Project  Management  Plan 


9-4 


Project  Execution-  (Rev.  5.3:  15  DEC  94) 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


■  Secure  Review/ Approval  of  Project 
Management  Plan 

■  Execute  Project  Management  Plan 

9.1.1  Review  Approved  Project-related 
Documents.  At  this  point  in  the  improvement 
project  a  number  of  documents  have  been  prepared, 
reviewed,  and  approved.  All  approved  documents 
are  input  to  project  planning.  The  principle 
documents  are  strategic  and  business  plans,  the  FEA 
and  supporting  documents,  the  technical  change 
management  plan,  organizational  change 
management  plan,  transition  plan,  and 
implementation  plan.  In  addition,  all  the 
information  systems  documentation  about 
platforms,  data  bases,  and  application  software  are 
applicable.  Finally,  architectures  and  configurations 
are  needed  to  develop  the  installation  and 
deployment  plan. 

Ultimately,  the  project  manager  must 
determine  what  has  to  be  done,  when  it  has  to  be 
done,  how  success  will  be  measured,  how  much 
funding  is  available,  and  what  resources  (human, 
machine,  and  facilities)  will  be  provided.  This 
information  should  be  contained  in  the  documents 
mentioned  above.  Clarification  and  additional 
information  will  be  needed  which  is  why  project 
planning  is  a  team  activity. 

The  important  thing  for  the  project  manager  to 
realize  is  that  the  project  plan  is  a  translation  of  all 
project  requirements  into  a  series  of  related  task 
assignments  with  deliverables  or  milestones, 
budgets,  schedules,  and  quality  objectives.  In  other 
words,  building  the  project  plan  requires  putting  all 
of  the  input  documentation  into  a  form  conducive  to 
management  and  control. 

Since  the  project  has  taken  some  months  to  get 
to  the  project  execution  phase,  it  is  likely  that  some 
of  the  documentation  used  as  input  is  out-of-date, 
incomplete,  or  just  plain  wrong.  Project  managers 
should  seek  clarification  on  any  element  of 
documentation  that  seems  suspicious.  Once  the 
project  plan  is  developed  and  approved,  it  becomes 
the  responsibility  of  the  project  manager  to  achieve 
success.  It  will  be  too  late  to  blame  execution 
problems  on  poor  input  documentation. 


9.1.2  Construct  Project  Management  Plan. 

From  the  input  documentation,  team  meetings, 
conferences,  research  and  investigation,  the  project 
manager  constructs  the  installation  and  deployment 
plan  using  project  management  techniques  and 
software  packages.  There  are  six  critical  elements 
in  the  project  plan: 

■  Work  Breakdown  Structure  (WBS).  The 
WBS  consists  of  all  the  tasks  that  must 
be  completed  during  the  installation  and 
deployment  period.  The  WBS  indicates 
the  sequencing  or  ordering  of  all  tasks 
and  shows  which  tasks  are  on  the  critical 
path,  which  tasks  must  be  completed 
before  others  can  start,  and  which  tasks 
can  be  completed  in  parallel.  The  critical 
path  consists  of  all  tasks  which  have  zero 
slack  meaning  that  a  delay  in  completing 
any  one  of  them  will  delay  the  project. 

■  Cost  Breakdown  Structure  ( CBS).  The 
CBS  shows  the  budgeted  funds  for  the 
completion  of  each  task  in  the  WBS. 
Because  tasks  will  cross  organizational 
boundaries,  the  CBS  can  be  used  to 
ascertain  each  department’s  share  of 
installation  and  deployment  costs.  The 
CBS  also  provides  an  effective  means  of 
managing  project  costs. 

■  Schedules  and  Milestones.  Tasks  are 
arranged  in  a  graphical  format  plotted 
against  time.  Each  task  will  have  a 
planned  start  time  and  may  have  early 
and  late  start  times  corresponding  to  the 
slack  time  built  into  the  schedule.  Each 
task  will  also  have  a  planned  duration 
and  planned  complete  time  and  may  have 
early  and  late  complete  times.  At  certain 
points  in  the  project  plan,  milestones  will 
be  indicated  which  provide  one  or  more 
critical  deliverables  and/or  a  formal 
review  and  evaluation  point. 

■  Resource  Allocation  Matrix  ( RAM). 

Tasks  require  resources  which  may  be 
any  combination  of  work  hours,  skills, 
equipment,  and  facilities.  Each  resource 
has  a  cost  associated  with  it.  The  RAM 
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shows  in  matrix  format  which  resources 
are  required  for  which  tasks  and  how 
long  those  resources  will  be  required. 

The  RAM  helps  managers  anticipate  and 
plan  for  needed  resources  so  that  the 
project  can  remain  on  schedule. 

■  Contingency  Plans.  All  projects  are 
subject  to  unanticipated  delays, 
problems,  and  events.  Every  unexpected 
glitch  will  affect  schedules,  costs,  and/or 
project  quality.  Good  project 
management  calls  for  contingency  plans 
to  be  put  in  place  especially  for  high-risk 
tasks.  The  minimum  reasonable  cost 
contingency  is  15%  of  overall  planned 
costs.  Some  high-risk  tasks  will  require 
a  higher  contingency,  some  routine  tasks 
may  not  require  any  cost  or  schedule 
contingency.  All  tasks  on  the  critical 
path  should  have  contingencies  in  place 
for  unforeseen  events.  Most  often,  this 
means  that  reserve  resources  should  be  in 
place  as  needed. 

■  Reporting  and  Meeting  Strategy. 

Projects  are  essentially  exercises  in 
effective  communication  and 
coordination.  This  requires  a  planned 
program  of  planning,  status,  and  issue 
resolution  meetings  combined  with 
regular  and  exceptional  reporting  and 
tracking  activities. 

Each  installation  and  deployment  project  will 
be  unique  which  is  why  constructing  project  plans  is 
so  important.  At  best,  general  planning  guidelines 
can  be  established  which  indicate  the  type  of  tasks 
that  should  be  considered  when  constructing  the 
project  plan.  The  following  areas  are  generally  part 
of  any  installation  and  deployment  program: 

■  Equipment  Deployment  (Computer, 
Communications,  and  Peripherals) 

■  Facilities  Acquisition  and  Refurbishment 
Including  Electrical  and  HVAC 

■  Fixtures  and  Furnishings  Acquisition  and 
Placement 


■  Health  and  Safety  Provisions 

■  Remote  Site  Support  including  Traveling 
and  Living  Arrangements 

■  Systems  Software 

■  Data  Acquisition,  Conversion  and  Data 
Base  and  File  Population 

■  Application  Software  (Acquired  and 
Developed) 

■  Process  Work  Flows  and  Stakeholder 
Relationships 

■  Policy,  Procedures,  Directives,  and 
Guidelines 

■  Manuals  and  Documentation  Production 
and  Distribution 

■  Staff  Communications,  Coordination, 
and  Problem  Resolution 

■  Employee  Union  and  Regulatory 
Relationships 

■  Staffing,  Classification  and  Job 
Descriptions 

■  Training  Administration  and  Delivery 

■  Supervision,  Reward  and  Recognition 
Provisions 

■  Organizational  Realignment  and 
Management  Structures 

■  Security,  Privacy,  Integrity,  Backup  and 
Recovery  Provisions 

■  Checkout  and  Acceptance  Provisions 

■  Conversion,  Parallel  Testing,  and  Cut¬ 
over  Provisions 

■  Installation  and  Post  Installation  Support 

■  Performance  Measures  and  Measurement 
Systems 

■  Process/Information  Systems 
Decommissioning  and  Salvage. 

Most  of  these  areas  have  been  addressed  at 
least  in  part  in  earlier  phases  of  the  project.  But 
now,  everything  must  be  brought  together  as  a 
complete  system.  Each  of  these  areas  must  be 
reconstmcted  as  a  network  of  tasks  with  schedules, 
budgets,  assignments,  and  contingencies.  It  can  be 
seen  that  some  of  these  areas  such  as  equipment 
acquisition  and  facilities  preparation  may  have  long 
lead  times.  This  means  that  project  planning  may 
have  to  commence  during  the  enterprise  engineering 
phase  of  the  project.  To  facilitate  such  situations, 
project  managers  will  generally  divide  the  project 
plan  into  major  phases.  Earlier  phases  will  be 
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planned  in  detail  while  later  phases  will  be  laid  out 
in  general  and  refined  as  the  time  to  begin  a  new 
phase  approaches.  The  major  phases  of  an 
installation  and  deployment  project  are  as  follows: 

■  Pre-Installation  Activities 

■  Installation  and  Checkout 

■  Initial  Training,  Operations,  and  Support 

■  Organizational  Deployment 

■  Post-Installation  and  Deployment 
Activities. 

Several  techniques  can  be  used  by  project 
managers  to  help  ensure  a  complete  and  workable 
project  plan.  The  most  important  is  the  Process 
Decision  Program  Chart  (PDPC).  This  is  an 
excellent  tool  for  ensuring  that  all  project  elements 
have  been  accounted  for  and  for  contingency 
planning.  This  technique  is  briefly  described  in 
section  10.  Additional  information  is  readily 
available  in  most  books  on  Total  Quality 
Management  practices.  Other  techniques  such  as 
those  described  in  section  10  are  useful  during  the 
project  execution  phase. 

9.1.3  Secure  Review/Approval  of  Project 
Management  Plan.  This  is  one  of  the  most  critical 
review  and  approval  points  in  the  entire  Framework 
methodology.  The  project  execution  plan  usually 
covers  the  widest  geography,  involves  the  most 
people,  represents  the  costliest  phase  of  the  project, 
and  is  subject  to  the  most  complexity  and  highest 
risks.  It  is  imperative  that  the  plan  be  thoroughly 
reviewed  and  accepted  by  all  parties  involved  in  the 
execution  phase  of  the  project.  It  may  take  from 
two  weeks  to  a  month  to  complete  project  review 
and  make  necessary  adjustments.  The  project 
manager  should  allow  for  the  project  plan  approval 
cycle  in  the  schedule. 

If  the  project  plan  is  developed  in  phases,  it 
will  be  necessary  to  review  each  phase  after  detail 
project  planning  is  completed.  Since  the  project  is 
planned  in  phases,  each  phase  review  will  only 
require  a  day  or  two.  Still,  these  review  points 
should  be  planned  with  enough  lead  time  to  ensure 
that  all  responsible  parties  are  available  to  complete 
their  review  in  a  timely  fashion.  Figure  9-1  shows 


how  the  project  plan  might  look  at  the  time  of  the 
first  review  and  approval  point.  The  Pre-installation 
plan  is  complete  and  detailed  in  all  respects.  The 
other  phases  are  partially  developed  and  reviewed 
as  an  in-process  deliverable.  As  the  Pre-installation 
phase  nears  completion,  the  Installation  and 
Checkout  phase  must  be  complete,  detailed,  and 
ready  for  ^al  review.  This  process  continuous 
throughout  the  phases  of  the  project. 

9.1.4  Execute  Project  Management  Plan.  Once 
developed  and  approved,  the  project  plan  becomes 
the  prime  driver  for  all  project  installation  and 
deployment  activities.  The  project  manager  has 
four  principle  duties: 

■  Project  performance  tracking 

■  Carry  out  cyclical  responsibilities 

■  Suspense  management 

■  Response  to  external  events. 

Project  performance  tracking  consists  of 
ensuring  that  task  work  starts  and  completes  on 
time,  within  budget,  and  at  the  acceptable  quality 
level.  All  deviations  to  schedule,  cost,  and  quality 
are  handled  as  exceptional  conditions  which  fall 
into  one  of  three  categories,  each  of  which  is 
handled  differently; 

■  Crises 

■  Problems 

■  Issues. 

Crises  are  unforeseen  events  that  represent  a 
risk  to  overall  project  goals  and  objectives.  A  true 
crisis  impacts  schedules,  budgets,  resources,  and/or 
quality.  Problems  can  be  characterized  as  follows: 

■  Can  be  stated  in  objective  terms 

■  Generally  affects  only  one  work-item  or 
task 

■  Is  a  clearly  defined  obstacle  to  work-item 
completion 

■  Generally  has  one  “best”  solution 

■  Agreements  on  problem  solutions  are 
easy  to  obtain 
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Figure  9-1.  Phased  Project  Planning  Review  Cycle 


■  Can  impact  all  project  factors;  costs, 
schedules,  resources,  scope,  and  quality. 

Cyclical  responsibilities  include  holding  on¬ 
site  inspections  and  conducting  progress  review  and 
coordination  meetings,  and  completing  and 
distributing  status  reports.  Project  management 
system  network  maintenance  is  also  a  cyclical 
responsibility. 

Suspense  management  consists  of  tracking 
problem  solving  assignments,  issue  resolution 
assignments  and  action  item  assignments. 

Response  items  include  data  calls  from  higher 
headquarters,  special  meetings,  outside  inspections 
and  tours,  and  handling  local  disasters  and 


■  Generally  impacts  costs,  schedules  or 
resources 

■  Generally  does  not  impact  project  scope 
or  quality. 

An  issue  can  be  characterized  as  follows: 

■  Cannot  be  completely  stated  in  objective 
terms 

■  Genereilly  affects  more  than  one  work- 
item 

■  Is  not  a  clearly  defined  obstacle  to  work- 
item  completion 

■  Generally  has  several  alternative 
resolutions 

■  Agreements  on  issue  resolution  are  not 
always  easy  to  obtain 
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unforeseen  events  such  as  floods,  storms,  riots,  etc. 
that  impact  project  performance. 

At  this  point,  the  reader  may  want  to  review 
project  management  leadership  qualities  listed  at  the 
beginning  of  this  phase.  A  full  accounting  of 
project  planning,  execution  management,  and 
tracking  can  be  found  in  the  Project  Manager’s 
Handbook  listed  in  appendix  B. 

9.2  Step  22:  Install/Deploy  Information 

Systems 

Systems  installation  and  deployment  is  an 
exercise  in  precision  coordination.  With  respect  to 
the  functional  user,  an  information  system 
installation  is  either  a  success  or  a  failure.  The  new 
system  works  or  it  doesn’t.  That  99.9%  of  the 
system  is  working  properly  is  of  little  concern  if  the 
0.1%  that  doesn’t  disrapts  operations,  frustrates 
users,  or  adversely  affects  customers. 

The  most  important  part  of  a  systems 
installation  is  the  project  execution  plan  developed 
in  the  previous  step.  If  the  plan  is  well  thought  out 
and  well  developed,  one  can  reasonably  expect  that 
the  execution  of  the  plan  will  be  within  normal 
success  limits.  While  there  will  be  problems, 
unforeseen  events  and  conditions,  and  issues 
associated  with  the  new  installation,  these  will 
likely  be  resolvable  with  reasonable  effort  and 
within  contingency  planning  parameters  of  cost  and 
time. 

The  most  important  principle  governing 
systems  installation  is  not  to  violate  the  installation 
plan  unless  it  can  be  shown  that  the  plan  is 
deficient.  Otherwise,  the  installation  team  will 
prove  the  axiom  that  there  is  never  time  or  money  to 
do  it  right,  but  there  is  always  time  and  money  to  do 
it  over.  To  avoid  becoming  trapped  in  this  axiom, 
there  must  be  milestones  and  checkpoints  in  the 
installation  process  to  ensure  that  the  installation  is 
going  as  planned.  Furthermore,  the  project  manager 
must  have  the  authority  to  halt  the  project  if  the 
conditions  established  for  a  given  set  of  milestones 
and  checkpoints  have  not  been  met.  The  countdown 
to  installation  must  not  resume  until  milestone  and 
checkpoint  discrepancies  have  been  removed. 


All  components  of  the  new  information 
system  should  be  in  place,  tested,  and  ready  for 
installation.  These  components  were  developed 
during  the  enterprise  engineering  phase  of  the 
project.  This  means  that  the  data  base  stmcture  is 
established  and  a  test  data  base  is  populated  ready 
for  systems  testing.  All  application  program 
modules  have  been  developed  and  unit  tested.  Final 
or  at  least  draft  documentation  is  in  place.  A  test 
program  has  been  established  that  will  test  all 
features  and  functions  of  the  system  including  its 
ability  to  recognize  and  trap  all  error  conditions. 
Finally,  initial  training  has  been  completed  for  those 
persons  who  will  participate  in  the  systems 
installation. 

If  a  new  information  system  is  being  installed 
to  support  a  radically  reengineered  business 
process,  it  may  be  quite  difficult  to  test  the  results 
produced  with  the  new  system  against  the  results 
produced  with  the  existing  system.  This  concept  is 
called  parallel  testing  and  works  well  when 
information  systems  are  being  upgraded  or 
enhanced.  It  also  works  well  in  the  case  of 
migration  systems  replacing  legacy  systems  with  no 
major  changes  to  the  business  processes  themselves. 
But  when  the  business  process  itself  has  been 
reengineered,  it  may  not  be  possible  to  conduct 
parallel  testing.  When  this  is  the  case,  greater  care 
must  be  exercised  during  the  systems  installation 
and  testing  period  to  ensure  that  the  new 
information  system  supports  the  way  the  new 
business  process  works. 

When  a  new  information  system  is  going  to  be 
used  in  more  that  one  geographical  location,  it  is 
wise  to  restrict  the  installation  process  to  a  single 
site.  When  the  new  system  is  proven,  it  can  then  be 
deployed  to  all  other  planned  sites.  Deploying  a 
poorly  tested  system  is  an  extremely  high-risk 
operation.  In  the  private  sector,  there  are  case- 
studies  of  how  failed  deployment  efforts  have 
destroyed  entire  enterprises.  The  risk  of  this 
happening  is  greater  when  the  new  information 
system  will  be  supporting  a  reengineered  business 
process. 
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This  Step  and  the  next  step — deploy 
organization  change  management  plan — are  closely 
related.  The  usual  procedure  is  to  install  the  new 
information  system  and  reengineered  business 
process  at  the  initial  installation  site,  then 
incorporate  all  organizational  changes  in  the  change 
management  plan  once  the  new  system  and  process 
are  working  well.  Organizational  changes  must  be 
installed,  tested,  and  revised  just  as  systems  and 
processes  must.  However,  during  deployment,  it  is 
customary  to  install  all  elements  at  the  same  time. 
These  are  the  elements  of  process,  system,  and 
organizational  change.  Because  deployment  is 
always  associated  with  changes  in  the  way  people 
perform  their  duties  and  the  way  they  work 
together,  it  takes  some  time  for  each  new 
installation  to  stabilize.  For  this  reason,  it  is  often 
advisable  to  establish  a  deployment  team  that 
moves  from  installation  to  installation  according  to 
a  phased  deployment  plan.  The  team  is  comprised 
of  staff  who  can  perform  all  installation  tasks 
including  training  and  intensive  personnel  support. 

The  tasks  performed  in  the  install/deploy 
information  systems  step  are  as  follows; 


■  Select  Initial  Installation  Site 

■  Install  and  Test  Information  Systems 

■  Implement  Training  Programs 

■  Conduct  Parallel  Test  Program 

■  Secure  Customer  Acceptance 

■  Implement  Transition  (Cut-over)  Plan 

■  Deploy  Remaining  Sites 

■  De-commission  Obsolete  Information 
Systems 

■  Conclude  Information  System 
Deployment  Phase 

The  first  five  tasks  in  this  step  establish  one 
working  installation  that  has  proved  the  operability 
of  the  information  systems  components,  validated 
the  change  management  plan,  and  passed  all 
customer  acceptance  tests.  Task  9.2.4 — conduct 
parallel  test  program — is  where  all  elements  of  step 
23 — deploy  organization  change  management 
plan — are  tested.  Figure  9-2  shows  the  first  five 
tasks  of  step  22 — install/deploy  information 
systems  which  are  concerned  with  the  initial 
installation  of  the  new  information  system. 


Figure  9-2.  Install  Information  Systems 


I 
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9.2.1  Select  Initial  InstaUation  Site.  The  initial 
installation  site  must  be  selected  and  prepared  with 
great  care  to  help  ensure  successlul  systems 
deployment  later  on.  The  criteria  for  site  selection 
include  the  following: 

■  Site  leadership  and  management  are 
committed  to  project  success 

■  Site  personnel  exhibit  high  morale  and 
are  receptive  to  change 

■  The  site  is  conveniently  located  relative 
to  technical  support 

■  The  site  performs  at  least  85%  of  the 
functions  of  the  business  process  and 
new  information  system 

■  The  site  is  representative  of  all  planned 
deployment  sites  with  respect  to  mission, 
goals,  objectives,  and  business 
operations 

■  The  physical  facility  is  adequate  for  the 
new  system  and  can  easily  accommodate 
the  installation  and  test  team 

■  The  site  offers  or  can  accommodate 
administrative  support  personnel  and  has 
adequate  communications  facilities  for 
voice,  data,  package  delivery,  and 
transportation 

■  Site  operations  can  tolerate  some 
dismption  to  normal  operations  during 
the  installation  and  test  period 

■  Customer  acceptance  of  the  new 
information  system  at  this  site  will  be 
recognized  and  supported  by  the  majority 
of  planned  deployment  sites. 

The  installation  team  must  ensure  sufficient 
lead  time  for  procuring  all  systems  components 
include  computer  and  communications  hardware, 
wiring  and  cables,  and  systems  software.  In 
addition,  the  site  must  be  certified  with  respect  to 
power,  air  conditioning,  and  ventilation  according 
to  hardware  vendor  specifications.  If  the  site  is  in 


an  area  subject  to  power  outages  or  fluctuations, 
adequate  backup  power  supplies  should  be  put  in 
place  so  that  testing  is  less  likely  to  be  disrupted. 

9.2.2  Install  and  Test  Information  Systems.  The 

first  task  after  site  selection  and  preparation  is  to 
install  and  test  all  hardware,  software,  and 
communications  components  and  facilities.  This 
phase  of  testing  should  be  completed  by  the 
installation  team  and  should  not  disrupt  normal 
business  operations  at  the  site.  It  is  best  if  site 
personnel  are  not  involved  in  the  installation  and 
checkout  process.  This  is  because  the  typical 
problems  encountered  in  the  initial  installation 
process  may  undermine  the  confidence  of  site 
personnel  in  the  new  system. 

The  install  and  test  program  will  be  quite 
similar  to  the  component  testing  program  performed 
in  the  enterprise  engineering  phase  of  the  project. 

In  fact,  it  is  best  if  these  tests  are  repeated  verbatim 
during  systems  installation.  This  way,  the 
installation  team  can  assure  itself  that  any  new 
problems  encountered  are  probably  associated  with 
the  new  variables  introduced  at  the  test  site,  not  the 
information  systems  components  as  they  left  the 
enterprise  engineering  phase. 

This  task  is  complete  when  all  features  and 
functions  of  the  system  have  been  successfully 
demonstrated.  This  includes  the  following: 

■  All  start-up,  sign-on,  password,  and 
security  features  are  fiinctional 

■  All  menu  selections  are  active  and 
branch  to  the  proper  systems  component 

■  All  screens  can  be  brought  up  and  add, 
change,  and  delete  functions  work 

■  All  reports  can  be  generated  and  major 
report  options  work 

■  All  transaction  types  and  codes  are 
accepted  by  the  system 

■  All  codes  and  tables  used  in  the  system 
are  populated  and  table  maintenance 
procedures  work 
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■  All  backup  and  recovery  functions  work 

■  All  personal  computers,  workstations, 
and  communications  nodes  can  access 
the  system  as  required 

■  Linkages  and  interfaces  to  other 
application  software  components 
including  off-the-shelf  software  packages 
work 

■  The  system  works  with  all  specified 
devices  including  brands  and  models  of 
input/output  devices,  storage  devices, 
communications  devices,  network 
devices  (local  and  wide  area), 
workstation  devices,  and  linkages  to 
other  computer  platforms. 

It  is  normal  to  encounter  even  severe  technical 
problems  during  the  initial  installation  and  systems 
test  process.  This  may  be  the  first  time  that  the 
system  is  tested  on  the  intended  computer  and 
communications  platform  and  new  variables  are 
introduced  that  were  not  present  during  the 
enterprise  engineering  phase.  For  this  reason, 
adequate  time  must  be  allotted  for  systems  testing. 

If  things  go  better  than  expected,  the  time  can  be 
profitably  used  to  do  more  thorough  testing. 

What  is  not  tested  in  this  task  is  the  logic  of 
the  application  functions  and  the  validity  of  the 
results  obtained.  For  instance,  this  task  will  test  that 
a  particular  report  can  be  printed  out,  but  it  will  not 
test  the  whether  the  data  displayed  in  the  report  is 
valid  or  whether  required  data  is  missing.  The  logic 
and  accuracy  of  the  system  will  be  tested  later  by 
site  personnel  who  are  expert  in  the  business 
process  and  the  functions  the  system  is  designed  to 
perform. 

Also,  the  installation  team  will  not  concern 
themselves  with  performance  tuning  during  this 
phase  of  the  project  unless  the  performance  is 
seriously  below  specification.  Performance  tuning 
is  normally  accomplished  following  operational  and 
parallel  testing  and  just  prior  to  running  final 
customer  acceptance  tests.  The  reason  for  this  is 
that  it  does  not  make  sense  to  tune  the  system  until 


all  errors  uncovered  by  operational  testing  are 
corrected. 

9.2.3  Implement  Training  Programs.  During  the 
later  stages  of  the  previous  task,  the  training 
program  developed  to  support  the  new  information 
system  should  be  delivered  to  site  personnel  who 
will  participate  in,  or  conduct  the  fimctional  tests  of 
the  new  information  system.  To  the  extent  that  it  is 
possible,  training  should  include  hands-on 
experience  with  the  new  information  system.  This 
can  be  provided  either  by  using  the  prototype 
system  that  was  developed  during  enterprise 
engineering  or  by  access  to  parts  of  the  newly 
installed  information  system  that  appear  to  be 
working.  Student  feedback  during  training  can 
often  be  helpful  to  the  installation  and  test  team. 

The  more  discrepancies  discovered  and  fixed  during 
installation  and  checkout,  the  less  there  will  be 
during  the  operational  testing  period. 

It  is  possible  that  the  training  systems 
developed  (or  being  developed)  for  general 
deployment  will  not  yet  be  ready  at  this  time.  This 
will  probably  be  the  case  if  some  form  of  media 
training  is  involved.  When  this  is  the  case,  it  may 
be  necessary  for  members  of  the  installation  and  test 
team  (rather  than  training  staff  or  contractors)  to 
conduct  the  initial  training.  If  this  will  be  the  case, 
time  must  be  allotted  in  the  installation  schedule  for 
this  to  take  place. 

The  project  team  should  be  aware  that  the 
training  system  being  used  at  this  time  is  also 
undergoing  final  tests.  If  allowance  is  made  to 
incorporate  student  feedback  into  refining  training 
materials,  the  training  program  deployed  with  the 
accepted  system  will  be  that  much  better.  Also, 
allowance  should  be  made  to  test  systems  and 
operational  documentation  so  that  any  discrepancies 
in  these  materials  can  be  corrected  prior  to  systems 
deployment. 

9.2.4  Conduct  Parallel  Test  Program.  This  task 
is  one  of  the  most  critical  in  the  entire  Framework 
methodology.  All  of  the  work  done  previous  to  this 
task  was  done  in  preparation  for  operational  and 
parallel  testing.  This  is  the  first  opportunity  for  all 
elements  of  the  business  process  reengineering 
program  and  its  underlying  information  systems 
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support  to  be  tested  together  by  the  functional 
people  who  work  in  the  business  process.  Also, 
during  this  period,  elements  of  the  organizational 
change  management  plan  will  be  tested  under 
operational  conditions. 

The  success  criteria  for  this  task  are  the 
following: 

■  Successful  systems  level  testing  results 
by  the  installation  team  resulting  in  a 
system  ready  for  operational  testing 

■  A  sound  training  program  that  prepares 
site  personnel  for  working  the  process 
and  using  the  new  information  system 

■  A  thoroughly  checked  out  organizational 
change  management  program  plan  ready 
to  be  phased  into  the  initial  test  site 

■  A  test  plan  with  accompanying  test  bed 
that  exercises  all  features  and  functions 
of  the  reengineered  process  and 
underlying  information  system 

■  A  program  of  regression  testing 
following  all  changes  or  fixes  to  any 
significant  element  in  the  process, 
information  system  or  change 
management  program. 

The  test  plan  must  be  carefully  constructed  so 
that  it  guides  testing  in  a  logical  order  with  respect 
to  the  sequence  of  process  operations  and  the 
structure  of  the  information  system.  An  information 
system  is  generally  tested  in  this  order: 

■  Data  base  records  and  tables 

■  Code  and  function  tables 

■  Global  functions  such  as  input/output, 
screen  generation,  and  data  base  access 

■  User  sign-on,  access  and  menu  systems 

■  Mainline  processing  functions  and 
routines  including  input  edit,  format,  and 
data  validation  routines 


■  Secondary  or  ancillary  functions  and 
routines  including  exception  handling 

■  Query  logic  and  report  generation 
routines  and  outputs 

■  Linkages  to  other  application  or 
packaged  software  programs 

■  Restore  and  restart  operations  with 
respect  to  operational  data 
reconstruction. 

All  test  sequences  must  be  conducted 
following  a  refresh  of  the  test  data  base  so  that 
consistency  of  operational  testing  can  be 
maintained.  All  errors  and  discrepancies  must  be 
recorded,  diagnosed,  coded,  corrected,  and  unit 
tested.  Changes  to  information  systems  must  be 
made  on  a  scheduled  batch  basis  followed  by 
implementation  of  a  regression  testing  program  to 
ensure  that  new  errors  are  not  introduced  in  parts  of 
the  system  already  tested.  Version  control  is  an 
absolute  must  during  this  process. 

When  the  entire  system  has  been  tested  and  all 
discrepancies  removed,  elements  of  the  change 
management  plan  can  be  introduced  to  ensure  that 
the  new  process  and  its  information  systems  support 
is  compatible  with  organizational  changes,  staff 
changes  and  assignments,  work  flow,  and  internal 
communications. 

When  this  process  is  complete,  then  (and  only 
then)  can  parallel  testing  commence.  Parallel 
testing  refers  to  the  technique  of  running  a  new 
system  side-by-side  with  the  existing  system  that  it 
will  replace.  The  purpose  is  to  ensure  that  the 
results  obtained  from  the  new  system  are  consistent 
with  the  results  obtained  from  the  existing  system 
for  similar  functions.  In  the  case  of  new 
functionality,  the  results  produced  by  the  new 
system  must  be  checked  against  the  new  policies, 
directives,  goals,  and  objectives  that  led  to  the 
introduction  of  the  new  process  and  information 
system  features.  In  most  cases,  the  TO-BE  activity 
and  data  models  and  the  prototype  system  (if  one 
exists)  can  be  used  to  perform  this  type  of 
validation. 
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The  secret  to  controlling  the  operational  and 
parallel  test  process  is  to  ensure  that  the  test  plan 
and  program  contains  checklists  that  reference 
every  area  of  process  changes  and  enhancements, 
organizational  changes,  and  information  systems 
functions  and  features.  Checklists  are  formal 
documents  that  are  time-stamped,  coded  by  system 
version  number,  and  signed  by  the  responsible 
person.  Errors  noted  on  checklists  should  also  be 
linked  to  program  modification  documents  so  that 
an  audit  trail  exists  relating  testing,  error  detection, 
error  correction,  and  regression  testing. 

When  the  test  program  is  complete,  all  errors 
and  discrepancies  have  been  properly  handled,  and 
all  regression  testing  activities  have  been 
completed,  the  installation  team  can  turn  then- 
attention  to  performance  tuning  of  the  system.  It  is 
likely  that  the  installation  team  working  with 
technical  support  can  optimize  data  base  structures, 
tables,  and  records,  enhance  menu  logic,  and 
streamline  internal  routines  that  affect  performance. 
Once  performance  tuning  has  been  accomplished,  a 
final  test  of  the  complete  system  must  be 
performed,  followed  by  efforts  to  clean  up  any 
documentation  and  training  discrepancies  that  result 
from  system  or  process  changes. 

9.2.5  Secure  Customer  Acceptance.  Customer 
acceptance  trials  are  only  performed  once  the 
installation  team  has  satisfied  itself  that  the  new 
process,  all  organizational  adjustments  and  changes, 
and  all  information  systems  are  ready  for  final 
inspection  and  acceptance.  The  overall  goal  of  this 
task  is  to  complete  Ae  customer  acceptance  trials 
with  little  or  no  new  errors  or  discrepancies 
reported.  In  addition,  this  is  a  time  for  customers  to 
identify  potential  enhancements  that  can  be 
considered  for  implementation  later  on. 

But  because  customer  acceptance  trials  are  a 
formal  process,  acceptance  must  be  based  on 
process  and  system  specifications  and  criteria,  not 
on  the  implementation  of  newly  requested  features 
and  enhancements.  The  reason  for  this  is  that  the 
entire  test  bed  and  test  program  was  constructed 
based  on  approved  process  and  system 
specifications  such  as  those  contained  in  models, 
plans,  designs,  and  the  FEA  that  authorized  the  new 


process  and  system.  If  new  changes  or 
enhancements  are  introduced  into  the  system  at  this 
stage  of  the  project,  there  is  no  assurance  that  such 
changes  can  be  adequately  tested.  In  any  case,  such 
action  would  invalidate  the  entire  system, 
operational,  and  parallel  testing  program. 

9.2.6  Implement  IVansition  (Cut-over)  Plan. 
Following  formal  customer  acceptance,  the 
transition  plan  previously  developed  is 
implemented.  The  transition  plan  governs  all 
activities  that  allow  the  organization  to  change  over 
to  the  new  process  and  system.  It  is  during  this  task 
that  the  organizational  change  management  program 
officially  goes  into  affect,  and  process  stakeholders 
(especially  suppliers  and  customers)  are  formally 
involved  with  die  new  system. 

If  the  previous  tasks  in  this  step  and  the 
corresponding  ones  in  step  23  have  been  faithfully 
executed,  the  transition  should  go  reasonably  well. 
However,  the  installation  team  and  site  personnel 
should  expect  some  problems  during  this  task. 

Some  of  these  problems  can  be  easily  handled,  but 
some  may  require  rethinking  parts  of  the  new 
implementation.  On  rare  occasions  (providing  the 
test  program  was  rigorously  carried  out),  the 
transition  program  may  have  to  be  halted  until 
serious  problems  and  issues  are  resolved. 

In  general,  the  project  should  be  considered  to 
be  in  the  transition  phase  until  one  complete 
business  cycle  has  been  completed.  This  will  most 
often  equate  to  one  month,  with  quarterly  and 
annual  functions  performed  at  least  once  on  a 
simulated  basis.  During  the  transition  period,  it 
may  be  necessary  to  force  some  exceptional 
conditions  that  rarely  occur  just  to  ensure  that 
everything  is  in  place  to  handle  these  exceptions. 
One  example  would  be  to  stage  a  power  failure  to 
ensure  that  recovery  procedures  are  effective. 

9.2.7  Deploy  Remaining  Sites.  Following  a 
successful  transition  period,  all  remaining  sites  can 
be  deployed  on  a  scheduled  basis  by  following  an 
abbreviated  installation  and  test  process.  The 
degree  of  site-specific  testing  and  acceptance  will 
depend  for  the  most  part  on  how  similar  each 
deployment  site  is  to  the  initial  site.  The  degree  of 
similarity  includes  leadership,  management,  and 
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employee  factors;  organizational  structure,  policy, 
and  procedure  factors;  product,  service,  and 
business  process  factors;  stakeholder  factors 
(especially  suppliers  and  customers);  and 
information  systems  utilization  factors.  The 
deployment  team  should  also  be  aware  of  physical 
site  characteristics  that  may  have  some  bearing  on 
successful  and  timely  deployment. 

In  general,  the  information  systems 
component  will  be  the  most  stable  and  consistent 
over  the  deployed  sites.  The  business  process  itself 
may  require  some  adjustments  or  changes  from  site 
to  site.  But  the  organizational  change  management 
program  may  have  to  be  implemented  quite 
differently  in  each  site.  The  only  way  to  know  these 
site-specific  characteristics  is  to  conduct  pre¬ 
deployment  visits,  meetings,  and  assessments 
during  the  project  execution  planning  step.  Another 
benefit  of  this  approach  is  that  a  preferred  sequence 
of  deployment  will  become  evident. 

One  of  the  most  important  considerations  of 
deployment  as  contrasted  with  initial  site 
installation  are  all  those  decisions  and  actions  that 
have  lead  time  associated  with  them.  Such  items 
include  site  preparation,  equipment  procurement, 
shipment,  and  installation,  organizational  changes, 
training  delivery,  technical  support,  and  transition 
planning.  It  is  very  important  that  the  overall 
project  management  plan  governing  installation  and 
deployment  have  well-developed  lead  time 
parameters  built  in  to  the  PERT  chart. 

Timing  will  be  affected  by  whether  there  will 
be  one  deployment  team  that  moves  from  site  to 
site,  or  multiple  deployment  teams.  An  additional 
consideration  is  how  much  of  the  deployment  work 
can  be  performed  by  site  personnel  versus  that 
which  is  to  be  performed  by  the  deployment  team. 

9,2.8  De-commission  Obsolete  Information 
Systems.  Following  a  successful  transition  period, 
the  next  task  is  to  de-commission  or  scrap  existing 
information  system  components.  While  hardware 
components  can  usually  be  salvaged  or  re-deployed, 
most  other  elements  associated  with  the  business 
process  and  underlying  information  system  are 
simply  scrapped.  The  following  activities  are 
performed  during  this  task: 


■  Accounting,  inventory,  and  maintenance 
records  are  appropriately  updated 

■  Supplier  agreements  and  contracts 
including  leases,  maintenance 
agreements,  supplies  contracts,  and 
services  contracts  are  properly  handled 

■  Licensed  software  packages  are  properly 
disposed  of 

■  Obsolete  documentation  (policies, 
procedures,  handbooks,  etc.),  special 
forms,  manuals,  and  training  courses  are 
scrapped 

■  Computer  and  communications 
equipment  is  scrapped,  salvaged,  or 
redeployed 

■  Obsolete  data  base  and  file  records  are 
archived  or  erased  as  appropriate. 

9.2.9  Conclude  Information  System  Deployment 
Phase.  The  final  task  in  this  step  is  to  officially  and 
formally  terminate  the  installation  and  deployment 
stage  of  the  project. 

For  the  most  part,  this  entails  the  following 
activities: 

■  Write  the  final  installation  and 
deployment  report  including  lessons- 
leamed  and  recommendations  for  future 
deployment  efforts 

■  Archive  installation  and  deployment 
related  materials 

■  Release  the  installation  and  deployment 
team  for  return  to  their  units  or 
reassignment 

■  Institute  planned  technical  and  operation 
support  services  including  telephone 
hotlines,  bulletin  board  services,  regular 
mailings,  training  services,  and 
documentation  distribution  services. 
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This  concludes  the  install/deploy  information 
systems  step. 

9.3  Step  23:  Deploy  Organization  Change 

Management  Plan 

Section  6  of  the  Framework  methodology  lays 
out  the  principles  of  developing  an  organizational 
change  management  plan.  The  Change 
Management  Tutorial  provides  additional  guidance 
on  how  to  construct  this  critical  plan.  At  this  point 
in  a  reengineering  project,  it  is  time  to  implement 
the  change  management  plan  along  with  process 
improvements  and  new  supporting  information 
systems. 

The  literature  makes  clear  that  most  failures 
associated  with  business  process  reengineering  are  a 
direct  consequence  of  poorly  developed  change 
management  plans,  poorly  implemented  change 
management  plans,  or  both.  The  most  common 
reasons  for  these  failures  are  lack  of  strong 
leadership  in  conjunction  with  poor 
communications  with  people  who  will  be  affected 
by  the  proposed  changes  to  process,  information 
systems,  and/or  organizational  structure  and 
operations.  If  the  principles  contained  in  section  6 
and  the  Change  Management  Tutorial  were 
followed  to  develop  the  change  management  plan, 
the  implementation  and  deployment  of  the  plan 
covert  in  this  step  of  the  Framework  methodology 
will  not  carry  the  Wden  of  trying  to  deploy  a 
flawed  plan. 

Business  process  changes  can  be  studied, 
analyzed,  modeled,  developed,  simulated,  and 
prototyped  in  a  laboratory  environment.  Since  most 
of  the  issues  associated  with  process  improvements 
are  objective  ones,  rational,  knowledgeable  people 
can  work  out  their  differences  with  approaches  and 
objectives.  The  same  is  true  of  information 
systems.  But  change  management  programs  cannot 
be  developed  and  tested  in  a  laboratory 
environment.  Organizations  are  too  dynamic,  and 
people  are  not  easily  analyzed  nor  can  their 
motivations  and  future  actions  be  reliably  predicted 
or  conditioned. 


This  means  that  the  implementation  of  an 
organizational  change  management  plan  must  be 
performed  under  actual  operating  conditions  and 
progress  must  be  monitored  over  time.  Only  then 
can  the  plan  be  demonstated  to  be  viable. 

Even  the  best  of  plans  will  need  to  be  adjusted 
to  accommodate  the  reaction  of  staff  and 
stakeholders  to  the  new  organizational  environment. 
This  requires  time  for  the  new  environment  to  settle 
in,  skilled  observation  of  the  new  dynamic  trying  to 
establish  itself,  reliable  feedback  from  those 
affected  by  the  change,  and  organizational-wide 
communications  and  cooperation  to  work  out  the 
problems  and  issues. 

The  Framework  methodology  calls  for  the 
initial  deployment  of  the  organizational  change 
management  plan  at  the  time  the  enhanced  process 
and  new  information  systems  are  being  installed  for 
operational  testing.  For  this  is  the  first  time  that  all 
elements  of  the  new  environment  can  be  brought 
together  and  studied  as  a  complete  system.  The 
organizational  change  management  plan  must  be 
validated  or  revised  as  indicated  before  full-scale 
deployment  can  begin.  It  is  absolutely  critical  that 
implementation  of  the  change  management  plan  be 
given  as  much  or  more  attention  as  the  new  process 
and  supporting  information  systems.  As  difficult  as 
it  can  to  work  out  the  problems  with  new 
processes  and  information  systems,  working  out  the 
problems  with  new  organizational  structures  is 
much  more  difficult. 

This  indicates  that  one  or  more  members  of 
the  installation  and  test  team  must  be  skilled  in 
organizational  dynamics  and  human  resource 
management.  The  task  of  validating  the  change 
management  plan  must  not  be  a  collateral  task 
assigned  to  technicians  and  business  analysts.  It 
also  means  that  the  leader  of  this  effort  must  have 
access  to  site  leadership  and  management 
throughout  the  initial  installation  and  test  period. 

Unlike  processes  and  systems  that  can  be 
fully  tested  and  validated  once  then  deployed  with 
little  risk,  every  deployment  site  is  a  custom 
installation  wiA  respect  to  the  organizational 
change  management  plan.  This  is  especially  true 
when  deployment  involves  different  regions  of  the 
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country,  different  components  within  DoD,  or 
different  operating  environments.  The  composition 
of  the  deployment  team  should  reflect  this  reality. 

The  following  tasks  are  performed  in  the 
deploy  organizational  change  management  plan 
step: 

■  Issue  Policy  and  Guidance 

■  Implement  Transition  Plan 

■  Deploy  Implementation  Plan 

■  Complete  Organizational  Realignment 

■  Changeover  to  New  Process  and 
Information  Systems 

■  Monitor  Change  Process 

■  Adjust  Program  as  Required 

■  Prepare  Final  Implementation  Report 

■  Conclude  Installation/Deployment 
Program 

These  tasks  as  described  below  assume  that  a 
well-constructed  and  approved  organizational 
change  management  plan  is  in  existence  and 
compatible  with  the  enhanced  or  reengineered 
business  process.  The  principles  and 
recommendations  below  are  invalid  if  this  is  not  the 
case. 

9.3.1  Issue  Policy  and  Guidance.  The  first  task  is 
to  inform,  then  educate  staff  on  the  policy  and 
guidance  that  will  be  put  into  effect  with  the 
enhanced  process  and  new  information  systems 
support.  It  does  little  good  to  implement  a  business 
process  that  enhances  customer  service  if  the  staff 
does  not  understand  that  improving  customer 
service  is  the  new  policy  of  the  organization.  The 
staff  also  has  a  need  to  see  how  new  directives, 
procedures,  and  methods  will  enable  them  to  carry 
out  the  new  policy. 

Conversely,  leadership  and  management  will 
want  to  know  if  there  are  any  flaws  in  the  new 
policy  and  guidance  that  should  be  addressed  before 
general  deployment  begins.  The  initial  installation 
of  the  new  process  and  supporting  information 
system  provides  a  laboratory  for  evaluating  policy 
and  guidance  under  operating  conditions. 

Therefore,  staff  at  the  initial  site  should  be 
empowered  to  evaluate  policy  and  guidance  as  they 


try  to  employ  it  and  recommend  changes  and 
enhancements.  To  a  lesser  extent,  this  will  be  true 
at  every  deployment  site.  It  can  be  expected  that  as 
deployment  continues,  fewer  problems  with  policy 
and  guidance  will  be  forthcoming. 

The  tendency  for  governmental  organizations 
to  lock-in  policy  and  guidance  before  gaining 
operational  experience  with  a  new  process  and 
system  must  be  overcome  in  the  spirit  of 
reinventing  government.  Otherwise  inconsistencies 
or  problems  that  arise  during  installation  and 
deployment  will  be  resolved  by  changing  the 
process  and/or  the  system  rather  than  the  policy  and 
guidance  even  when  it  can  be  demonstrated  that  the 
policy  or  guidance  is  what  should  be  changed. 

932  Implement  If'ansition  Plan.  The  period  of 
time  that  begins  with  the  introduction  of  a  new 
operating  environment  (process,  system,  and 
organization),  and  ends  with  the  de-commissioning 
of  the  existing  process  and  system  is  known  as  the 
transition  period.  This  is  a  particularly  trying 
period  for  organizations.  The  old  environment 
(process,  system,  and  organization)  is  still  in  place. 
The  staff  is  trying  to  convert  to  a  new  environment. 
And  as  the  installation  proceeds,  the  staff  is  trying 
to  operate  in  elements  of  the  new  environment. 

The  transition  plan  is  primarily  concerned 
with  guiding  staff  and  management  through  the 
installation  and  deployment  process.  In  other 
words,  it  is  people-intensive.  The  implementation 
plan  described  in  the  next  task  is  concerned  with  the 
mechanics  of  making  the  transition  and  is  focused 
on  structural  and  operational  issues. 

There  is  probably  no  such  thing  as  a  smooth 
transition  in  this  situation,  but  there  is  a  very  high 
risk  of  a  complete  failure  to  make  the  transition. 

The  transition  plan  was  developed  earlier  in  the 
process  and  now  it  is  time  to  put  it  into  effect. 

Doing  so  will  require  forceful  leadership,  sensitive 
management,  and  excellent  project  management 
skills.  People’s  lives  and  careers  are  being 
dismpted  and  personal  and  organizational  stress  will 
be  at  a  maximum  during  the  transition  period. 
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Even  a  well-developed  transition  plan  will 
need  to  be  closely  monitored  during  execution,  and 
changed  to  fit  events  and  circumstances  as  they 
occur.  Normal  resistance-to-change  factors  must  be 
dealt  with  as  they  occur.  Informal  leaders  must  be 
recognized  and  supported  as  they  emerge.  Personal 
situations  that  develop  must  be  handled  confidently 
but  with  some  sensitivity.  The  staff’s  awareness  of 
how  leadership  and  management  perform  during 
this  period  will  be  heightened  and  they  will  respond 
accordingly. 

Project  managers  should  continually  observe 
the  reaction  of  staff  to  the  events  taking  place 
during  the  transition  period.  Arnold  S.  Judson^® 
suggests  the  spectrum  of  behaviors  toward  change 
presented  in  figure  9-3.  When  positive  behaviors 
are  observed,  they  should  be  immediately 
recognized  and  rewarded.  Neutral  behaviors 
suggest  that  some  form  of  coaching  or  counseling  is 
necessary.  Negative  behaviors  must  be  severely 
dealt  with  before  they  compromise  the  success  of 
the  project. 

The  initial  site  installation  provides  an 
opportunity  to  validate  and  improve  the  transition 
plan  that  will  be  used  throughout  the  deployment 
period.  However,  it  must  be  emphasized  that  each 
deployment  site  will  be  somewhat  unique  and  will 
present  its  own  set  of  problems  and  circumstances. 
This  means  that  every  site  will  require  a  customized 
transition  plan  deployment.  To  the  extent  that  it  is 
possible,  the  transition  team  should  work  with  each 
deployment  site  in  advance  of  installing  the  new 
process  and  information  system.  This  way,  obvious 
adjustments  can  be  made  to  the  transition  plan  for 
each  site  before  the  situation  is  complicated  by  the 
installation  of  the  process  and  system. 

9.3.3  Deploy  Implementation  Plan.  The  specific 
sequence  of  actions  that  must  be  taken  to  switch 
over  to  the  new  operating  environment  is  contained 
within  the  implementation  plan.  A  well-developed 
implementation  plan  will  have  actions,  criteria, 
assignments,  schedules,  resources  needed,  and 
costs.  It  will  also  have  milestones  or  coordination 


points  to  synchronize  actions  taken  by  different 
people.  During  the  initial  installation,  problems 
with  the  implementation  plan  may  be  discovered, 
and  enhancements  to  the  plan  may  be 
recommended.  Following  each  deployment, 
lessons-leamed  can  be  used  to  improve  the  plan  still 
further. 

One  of  the  primary  activities  performed  during 
implementation  is  training  delivery  to  all  staff  and 
management  involved  with  the  new  business 
system.  Experience  has  shown  that  one  of  the  most 
effective  ways  to  train  staff  when  major  dislocations 
in  work  processes  and  organizational  structure  are 
involved  is  to  require  management  and  supervision 
to  participate  in  training  delivery.  This  is 
accomplished  by  first  training  management  and 
supervision,  then  training  them  on  how  to  deliver 
the  training  program  (train-the-trainer),  then  having 
them  deliver  the  training  program  to  their  own  staff 
with  the  assistance  of  professional  trainers. 

The  implementation  of  organizational  changes 
must,  of  course,  be  coordinated  with  the 
implementation  of  process  changes  and  new 
information  systems.  Unlike  process  and  systems 
change  schedules,  the  implementation  of 
organizational  changes  must  factor  in  the  speed  at 
which  people  can  understand  and  assimilate 
changes  that  affect  their  work  and  their  interactions 
with  others.  Allowances  must  be  made  for 
individual  differences  and  circumstances  if 
resistance  factors  are  to  be  contained. 

9.3.4  Complete  Organizational  Realignment. 

During  the  customer  acceptance  trials  described  in 
task  9.2.5,  the  final  organizational  environment 
must  be  established  in  preparation  for  switching 
over  to  the  new  process  and  system.  Organizational 
and  management  structures  should  be  in  place, 
staffing  changes  should  be  implemented,  employee 
assignments,  both  individual  and  team,  should  be 
established,  and  all  support  mechanisms  should  be 
ready  to  be  activated. 


8  Arnold  S.  Judson,  Changing  Behavior  in  Organizations:  Minimizing  Resistance  to  Change,  Cambridge,  Mass.: 
Blackwell,  1991. 
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The  Spectrum  of  Possible  Behavior  Toward  Change 

Acceptance 

Enthusiasm 

Cooperation 

Cooperation  under  pressure  from  management 

Acceptance 

Passive  resignation 

Indifference 

Indifference 

Apathy:  loss  of  interest  in  the  job 

Doing  only  what  is  ordered 

Regressive  behavior 

Passive  Resistance 

Nonleaming 

Protests 

Working  to  rule 

Doing  as  little  as  possible 

Active  Resistance 

Slowing  down 

Personal  withdrawal  (excessive  absences) 

Committing  “errors" 

Spoilage 

Deliberate  sabotage 

Figure  9-3.  Spectrum  of  Behavior  Toward  Change 


Procedures,  methods,  techniques,  and  tools  for 
conducting  business  operations  should  be  in  place, 
and  obsolete  items  disposed  of.  The  objective  is  to 
have  the  organization^  realignment  complete  by  the 
time  the  customer  acceptance  trials  are  concluded. 
During  this  period,  all  remaining  problems  and 
issues  should  be  identified,  diagnosed,  and  resolved 
(or  scheduled  for  resolution). 

9.3.5  Changeover  to  New  Process  and 
Information  Systems.  This  task  coincides  with 


task  9.2.6:  Implement  Transition  (Cut-over)  plan. 
This  point  in  time  is  T-0  (T-  zero)  with  respect  to 
launching  the  new  business  system.  Everything  that 
can  be  done,  has  been  done,  and  the  organization 
begins  operating  in  the  new  work  environment. 
When  possible,  the  changeover  should  be  scheduled 
to  coincide  with  a  slack  period  in  the  business  cycle. 
For  instance,  it  is  usually  not  a  good  idea  to  launch 
a  new  business  system  during  budget  preparation 
periods. 
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93.6  Monitor  Change  Process.  It  takes  about  six 
months  for  people  to  adjust  to  a  new  working 
environment  following  changeover.  During  this 
period  of  time,  it  is  important  to  monitor  operations 
and  secure  staff  and  stakeholder  feedback.  In  all 
but  the  simplest  of  working  environments,  events 
and  situations  will  develop  that  were  not  accounted 
for  during  the  planning,  design,  and  implementation 
stages  of  the  project.  These  exceptional  conditions 
should  be  monitored  so  that  both  temporary  and 
permanent  resolutions  can  be  found. 

Furthermore,  employees  are  more  likely  to 
succeed  in  the  new  environment  if  they  have  the 
means  to  communicate  their  experiences  and 
suggest  improvements.  This  is  often  called  hand¬ 
holding  but  it  is  quite  important  to  the  overall 
success  of  the  project.  Since  some  employees  are 
not  comfortable  dealing  with  supervision  in  these 
matters,  it  is  helpful  if  a  member  of  the  installation 
or  transition  team  is  available  for  employees  to 
talk  to. 

9.3.7  Adjust  Program  as  Required.  Any 
reluctance  to  enhance  elements  of  the  improvement 
program  whether  process,  information  system,  or 
organizational  should  be  actively  discouraged.  In 
the  information  age,  change  is  the  norm.  All 
enterprises  are  encouraged  to  become  learning 
organizations  where  the  potential  is  for  each 
working  day  to  be  a  little  more  effective  and 
efficient  than  the  day  before.  This  can  only  happen 
when  staff  are  encouraged  to  look  for  improvements 
and  to  expect  that  appropriate  action  will  be  taken 
when  they  do  submit  improvement  ideas.  It  is  even 
better  when  employees  are  empowered  to  make 
improvements  within  their  authority  as  they  see  fit. 

This  can  happen  in  organizations  where 
policies  replace  rales,  guidelines  replace 
procedures,  and  education  enhances  training.  When 
staff  come  up  with  new  ideas,  suggestions,  and 
methods,  there  should  be  a  provision  to  incorporate 
these  into  the  overall  improvement  program  and 
deploy  the  results  as  appropriate. 

9.3.8  Prepare  Final  Implementation  Report. 

Following  the  cut-over  to  the  new  environment,  a 
preliminary  implementation  report  should  be 
prepared  and  submitted  to  designated  review  boards 


and  agencies.  About  six  months  after  an 
installation,  a  final  implementation  report  should  be 
prepared  and  submitted.  This  report  should  indicate 
as  precisely  as  possible,  performance  versus  plan. 
For  the  most  part,  the  implementation  report  should 
reference  the  FEA  which  describes  the  benefits  to 
be  achieved  in  return  for  the  investment  to  be  made. 
Objective  factors  such  as  customer  service,  product 
quality,  cycle  time,  and  cost  savings  are  the  nucleus 
of  the  report. 

While  six  month’s  worth  of  operations  is  not 
sufficient  to  demonstrate  that  the  new  business 
system  fulfills  all  planning  and  design  objectives,  it 
should  be  sufficient  to  show  trend  data.  Follow-up 
reports  will  confirm  or  deny  the  trends. 

An  important  part  of  the  implementation 
report  is  lessons-leamed  and  suggestions  for  future 
improvements.  When  possible,  it  is  also  useful  to 
capture  stakeholder  comments  including  those  who 
are  part  of  the  process.  The  final  implementation 
report  should  be  a  primary  input  to  the  next 
improvement  cycle  for  the  business  process  and 
underlying  information  systems. 

9.3.9  Conclude  Installation/Deployment 
Program.  There  must  be  a  formal  close  to  the 
installation  and  deployment  stage  of  the  project.  In 
general,  the  installation  period  concludes  about  six 
months  after  the  cut-over  or  until  all  customer 
acceptance  documents  have  been  signed.  At  this 
time  installation  and  deployment  teams  can  be 
officially  closed  out  and  all  personnel  not  already 
relieved  should  be  reassigned  as  agreed  upon.  At 
this  time,  the  project  enters  the  operations, 
maintenance,  and  enhancement  stage  which  is  on¬ 
going  until  the  end  of  the  process  life-cycle.  The 
most  important  aspect  of  ^is  task  is  that 
responsibility  and  authority  for  the  business  system 
is  transferred  from  the  installation  and  deployment 
team  to  site  management. 

This  concludes  the  deploy  organizational 
change  management  plan  step. 
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9.4  Step  24:  Operate/Maintain  Process  and 
Information  Systems 

The  purpose  of  process  innovation  or 
reengineering  is  to  achieve  a  dramatic  improvement 
in  process  performance  in  terms  of  quality,  service, 
cycle  time,  and  cost  efficiency.  If  all  has  gone  well 
in  implementing  the  Framework  methodology  to 
this  point,  that  objective  has  been  achieved.  This 
step  is  concerned  with  maintaining  the 
improvements  achieved  and  ensuring  that  the 
process  does  not  degenerate  in  terms  of  the 
measures  established  to  monitor  process 
performance. 

Processes  can  degenerate  for  several  reasons. 
Conditions  change  constantly  in  the  external  and 
internal  environment  which  can  de-optimize  process 
performance.  Managers  can  fail  to  adequately 
monitor  process  performance  and  allow  sub¬ 
standard  inputs  to  contaminate  process  operations. 
Employees  can  lose  their  focus  on  providing 
superlative  customer  service  and  fall  back  into  old 
work  methods.  Staff  turnover  in  the  absence  of 
effective  training  and  coaching  practices  can  lower 
the  organization’s  ability  to  perform  at  the  level 
achieved  by  process  engineering. 

Process  management  is  active,  continuous,  and 
rigorous.  Performance  measures  must  be  monitored 
to  spot  exceptional  conditions  and  negative  trends. 
Customers  (both  internal  and  external)  must  be 
continually  monitored  to  ensure  that  their  needs  and 
requirements  are  being  met.  Supplier  partnerships 
must  be  pro-active  to  ensure  that  agre^  upon  input 
quality  and  service  levels  are  maintained.  Finally, 
employees  must  be  fully  engaged  in  process 
performance  and  empowered  to  take  fast, 
resourceful  action  to  prevent  or  solve  process- 
related  problems. 

Process  management  is  also  concerned  with 
maintaining  an  orderly  environment  that  facilitates 
staff  productivity.  Resources  are  available  as 
needed  so  that  employees  can  do  their  jobs. 
Documentation  is  properly  maintained.  Data 
sources  are  available  as  needed.  The  work  facility 
is  clean,  neat,  comfortable,  safe,  and  secure. 


Finally,  process  management  is  concerned 
with  maximizing  communications  within  the 
enterprise  so  that  everyone  understands  what  is 
expected  of  them,  how  their  individual  and  team 
performance  measures  up  to  expectations,  and  the 
consequences  (good  or  bad)  of  their  performance. 
Fear,  uncertainty,  and  doubt  have  no  place  in  an 
organization  operating  under  good  process 
management  principles. 

Information  systems  management  with  respect 
to  operations  and  maintenance  means  that 
functional  users  and  managers  are  active 
participants  in  all  activities  involving  information 
systems  support.  The  information  system  exists  to 
support  process  requirements.  There  is  no  other 
reason  for  having  one.  Since  functional  managers 
are  charged  with  responsibility  for  process 
performance,  they  are  also  responsible  for  ensuring 
that  information  systems  support  is  focused  on 
serving  process  requirements. 

The  following  tasks  are  performed  in  the 
operate/nuuntain  process  and  information  systems; 

■  Operate  Process  and  Information 
Systems 

■  Monitor  Performance 

■  Identify/Classify/Resolve  Problems  and 
Issues 

■  Maintain  Process  and  System 
Documentation 

■  Conduct  Continuous  Training  and 
Support  Program 

■  Prepare  Regular  Operating  Status 
Reports 

9.4.1  Operate  Process  and  Information  Systems. 

The  laws  of  thermodynamics  are  said  to  govern  all 
activity  in  our  universe  including  human  activity. 
One  wit  has  said  that  the  first  law  of 
thermodynamics  says  that  you  can’t  win,  and  the 
second  says  that  you  can’t  break  even  either.  What 
these  laws  are  re^y  saying  is  that  left  alone,  every 
system  will  degenerate  over  time.  They  also  say 
that  to  maintain  the  performance  level  of  a  system, 
energy  must  be  continuous  injected  into  the  system. 
Whether  these  laws  apply  to  every  situation  in  the 
universe  or  not,  they  do  apply  to  process 
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management.  Process  management  is  an  active,  on¬ 
going,  energy-injecting  exercise.  When  effective 
process  management  is  practiced  on  a  daily  basis, 
processes  tend  not  to  deteriorate  over  time. 

There  are  seven  keys  to  process  management. 
Each  of  these  keys  plays  an  important  role  in 
ensuring  that  the  process  is  at  least  maintaining  the 
effectiveness  and  efficiency  engineered  into  it 
during  the  process  improvement  project. 

■  Process  Ownership.  Every  process  must 
have  a  designated  process  owner  with  the 
authority  to  negotiate  cross-functional 
interactions.  Assuming  a  well-trained 
and  empowered  staff,  most  process 
problems  are  the  result  of  breakdowns  at 
internal  and  external  process  boundaries 
and  interfaces.  The  role  of  the  process 
owner  is  to  monitor  cross-functional 
situations  and  events  and  take  immediate 
corrective  action  as  indicated. 

■  Boundary  Management.  A  process 
boundary  exists  wherever  the  handoff  of 
a  work  product  occurs.  Most  of  the 
process  boundaries  in  a  typical  process 
are  internal — across  functional 
boundaries  within  the  organization. 

Other  boundaries  are  external — ^usually 
between  the  enterprise  and  its  suppliers 
and  customers.  There  is  a  contract  in 
place  that  governs  the  conditions  of 
transferring  work  products  across 
boundaries.  Most  of  these  contracts  are 
implied  with  respect  to  internal 
boundaries,  and  expressed  with  respect 
to  external  boundaries.  Whether  implied 
or  expressed,  work  contracts  must  be 
actively  managed  to  ensure  that  all 
parties  are  living  up  to  their 
responsibilities  to  meet  all  performance 
standards  for  handing  off  work  products. 

■  Monitor  Workflows.  During  process 
improvement,  a  TO-BE  activity  model 
was  developed  showing  the  activities  that 
make  up  the  process  and  how  data  and 
material  move  between  and  among 
processes.  Now  that  the  new  process  is 


in  operation,  these  workflows  must  be 
monitored  to  ensure  that  all  process 
objectives  are  being  met.  It  is  possible 
that  the  activity  model  does  not  account 
for  all  exceptional  conditions,  or  that 
some  activities  need  to  be  optimized  or 
re-sequenced  to  improve  workflows  and 
work  product  quality. 

■  Monitor  Customer  Requirements.  The 
primary  purpose  of  a  process  is  to 
provide  a  product  or  service  that  satisfies 
customer  requirements  within  a  system 
of  agreed  upon  constraints.  This  is  true 
whether  customers  are  internal  or 
external.  It  is  necessary  to  ensure  that 
the  process  is  doing  this  on  a  continuing 
basis.  This  means  that  process  owners 
and  participants  should  regularly  query 
their  customers  to  ensure  that  needs  are 
being  met,  and  also  to  find  ways  of 
improving  customer  service.  Some  ideas 
can  be  immediately  adopted,  others  may 
provide  inputs  for  future  process 
improvement  projects. 

■  Monitor  Control  Points.  Control  points 
were  established  during  process 
improvement  and  reengineering.  Each 
control  point  was  designed  to  provide 
data  that  indicates  how  the  process  is 
performing  with  respect  to  its  design 
objectives.  Most  control  points  are 
established  at  process  boundaries  and 
interfaces.  There  is  no  reason  to  have 
control  points  if  they  are  not  going  to  be 
monitored.  Most  control  points  are 
monitored  on  a  daily  basis  although 
some  may  require  more  frequent  or  less 
frequent  monitoring.  A  good  system  of 
control  points  provides  data  to  process 
participants  so  that  they  can  take 
immediate  corrective  action  when 
problems  occur  or  trendlines  are 
deteriorating.  Some  control  points 
provide  management  data  that  indicate 
that  a  cross-functional  situation  may  be 
developing  that  is  outside  the  control  of 
work  teams. 
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■  Measure  Process  Performance. 

Processes  are  designed  to  carry  out  the 
mission,  goals,  and  objectives  of  the 
enterprise.  Control  points  provide  raw 
data  about  process  performance.  Process 
owners  and  others  must  analyze  the  raw 
data  provided  by  the  control  points  with 
respect  to  agreed  upon  standards  of 
performance.  When  there  is  a  significant 
deviation  in  performance  to  standard,  or 
when  trend  data  indicates  deterioration, 
process  owners  must  take  corrective 
action. 

■  Obtain  Feedback  from  Process 
Stakeholders.  A  process  may  be 
satisfying  all  design  objectives,  and 
process  performance  may  be  acceptable 
based  on  measurement  data;  but 
circumstances  may  have  changed 
stakeholder  needs,  requirements,  and 
desires.  Periodically,  every  process 
should  be  assessed  with  respect  to  how  it 
is  serving  current  stakeholder 
requirements.  If  stakeholder  needs  have 
changed,  it  may  be  necessary  to  make 
adjustments  in  the  way  the  process 
works. 

One  of  the  most  important  elements  of  process 
management  is  to  ensure  that  staff  (process 
participants)  are  performing  at  optimum  levels,  and 
that  their  needs  as  employees  and  as  humans  are 
being  met.  This  means  that  communications  must 
be  open  and  effective  so  that  employees  can  make 
their  maximum  contribution.  Information  must  be 
available  and  flow  freely  throughout  the 
organization.  And,  training  programs  must  be 
available  so  that  employees  can  develop  both 
interpersonal  and  job  sldlls  required  for  effective 
team  participation. 

9.4.2  Monitor  Performance.  The  purpose  of 
process  reengineering  is  to  develop  high- 
performance  processes.  The  purpose  of 
performance  monitoring  is  to  keep  reengineered 
processes  from  deteriorating  or  degrading.  The 
truth  is  that  most  organizations  do  a  poor  job  of 
monitoring  process  performance.  This  is  evident  by 
the  amount  of  time  most  organizations  spend  in  so- 


called  firefighting  activities.  Firefighting  almost 
always  results  in  a  quick-fix  being  applied  to  solve 
the  problem.  A  quick-fix  addresses  the  symptoms 
of  a  problem  rather  than  its  root  causes.  After 
enough  quick-fixes  have  been  superimposed  on  a 
process,  the  overall  effectiveness  and  efficiency  of 
the  process  deteriorates. 

In  monitoring  process  performance,  process 
owners  look  for  two  situations.  The  first  situation  is 
when  an  exceptional  event  occurs  outside  the 
performance  parameters  established  for  the  process. 
The  second  situation  is  when  a  pattern  of 
deterioration  occurs  that  indicates  that  the  process  is 
breaking  down  and  will  eventually  fail  to  deliver 
quality  products  or  services. 

The  first  situation  usually  has  a  definite  cause. 
The  cause  can  be  a  defect  in  incoming  data  or 
material,  an  equipment  or  system  breakdown,  or  an 
employee  error.  It  is  important  to  find  the  root 
cause  of  an  exceptional  condition  so  that  the 
problem  can  be  fixed  at  the  source.  In  this  way,  the 
likelihood  of  a  recurrence  of  the  problem  is 
minimized.  For  example,  if  a  problem  is  caused  by 
bad  material,  the  source  of  the  bad  material  must  be 
determined,  and  the  cause  eliminated.  A  quick-fix 
would  be  to  correct  the  bad  material  and  continue. 
This  would  do  nothing  to  prevent  future  material 
defect  problems. 

The  second  situation  is  usually  a  result  of  a 
deterioration  somewhere  in  the  process.  It  can  be  a 
machine  tool  wearing  out,  employees  with  personal 
problems  that  affect  their  job  performance,  or  a 
basic  defect  in  the  process  itself.  These  kinds  of 
problems  can  be  difficult  to  solve  especially  in 
service-based  processes.  Brainstorming  along  with 
cause  and  effect  analysis  is  called  for  to  solve  these 
kinds  of  problems. 

Other  things  that  are  monitored  include  overall 
customer  satisfaction,  worker  productivity,  schedule 
performance,  budgets  and  expenses,  and  quality.  A 
well-designed  process  will  have  control  points  and 
metrics  to  facilitate  this  kind  of  process  monitoring. 
Many  of  the  techniques  and  tools  described  in 
section  10  in  this  guidebook  can  be  used  to  monitor 
process  performance. 
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9.4.3  Identify/Classify/Resolve  Problems  and 
Issues.  Effective  organizations  actively  seek  out 
problems  and  issues  so  that  they  can  be  dealt  with 
before  they  lead  to  process,  product,  or  stakeholder 
problems.  For  instance,  airline  inspectors  often  fly 
incognito  to  experience  the  service  of  the  airline 
from  the  customer’s  perspective.  Some 
organizations  use  quality  circles  to  solicit  input 
from  employees  on  actual  or  potential  problems.  It 
is  common  practice  in  government  to  log  lessons- 
leamed  after  the  completion  of  every  project. 

While  it  is  admirable  to  identify  problems  and 
issues,  it  is  only  effective  if  these  problems  and 
issues  are  classified,  analyzed,  and  resolved. 

Process  owners  often  find  it  useful  to  keep  a  process 
log  or  notebook  to  record  all  incidents,  problems, 
and  issues  associated  with  their  process.  This  log 
provides  input  for  planning  sessions,  process 
improvement  actions,  and  problem-solving 
conferences.  There  are  several  commercial 
software  packages  available  that  accept  free-form 
data  entry  and  then  provides  techniques  to  classify 
and  analyze  this  data  in  many  interesting  ways. 

With  this  software,  patterns  can  be  discovered  that 
would  be  very  difficult  to  discern  manually.  Most 
of  these  packages  also  include  the  means  to  track 
actions  and  activities  that  result  from  the  analysis  of 
the  input. 

Many  of  the  techniques  described  in  section 
10  can  be  used  to  classify  and  resolve  problems  and 
issues.  But  they  can  only  be  used  if  first,  the  data  is 
collected  and  maintained. 

9.4.4  Maintain  Process  and  System 
Documentation.  Effective  process  management 
requires  a  concerted  effort  to  maintain  all  process 
and  systems  documentation.  This  can  only  be  done 
when  most  or  all  documentation  is  maintained  on 
automated  systems.  Process  owners  must  ensure 
that  any  change  to  the  process  or  its  underlying 
information  system  is  immediately  reflected  in  the 
appropriate  documentation.  For  processes,  it  is 
especially  important  to  maintain  activity  and  data 
models  because  they  are  the  basis  for  making 
improvements  in  the  future.  Once  a  TO-BE  model 
is  implemented,  it  automatically  becomes  the  AS-IS 
model.  Process  designers  will  rely  on  the  accuracy 


and  completeness  of  this  documentation  during 
future  improvement  projects. 

One  of  the  most  important  documents  to 
maintain  is  the  process  notebook  described  earlier 
in  this  guidebook.  Like  a  ship’s  log,  the  process 
notebook  can  be  a  reliable  reference  document  for 
the  entire  history  of  the  process.  As  such,  it  can  be 
used  to  support  both  process  management  and 
process  improvement  activities. 

9.4.5  Conduct  Continuous  Training  and  Support 
Program.  The  most  effective  enterprises  highly 
value  training  as  an  enabler  of  superior 
performance.  There  are  two  types  of  training 
involved  in  process  management.  One  type  refers 
to  formal  training  programs  designed  to  impart 
specific  knowledge  or  skills  related  to  process  work. 
TTie  second  type  refers  to  informal  training 
exercises  that  can  be  a  routine  part  of  the  job.  One 
of  the  primary  advantages  of  establishing  a  work 
team  environment  is  that  each  member  of  the  team 
can  learn  from  others. 

It  is  up  to  process  owners  and  management  to 
help  establish  the  training  objectives  for  formal 
training  programs  as  well  as  encourage  lots  of 
informal  on-the-job  training.  Employee’s  work 
schedules  should  not  be  so  intense  that  there  is  no 
time  for  learning  activities.  Many  mangers  find  that 
incorporating  short  training  sessions  into  regular 
staff  meetings  is  an  effective  way  to  communicate 
the  value  management  places  on  training  as  a 
regular  part  of  job  responsibilities. 

Front-line  workers  are  those  who  work 
directly  with  a  product  or  service,  or  who  face  the 
customer.  It  must  be  remembered  that  the  entire 
organization  exists  to  provide  products  and  services 
to  customers.  Everything  else  is  non-value  added 
from  the  customer  perspective.  Therefore,  the 
entire  organization  as  a  whole  (including 
management)  can  be  looked  upon  as  a  support 
organization  for  front-line  workers.  With  this 
perspective,  process  owners  and  process  managers 
strive  to  find  ways  to  support  their  front-line 
workers  on  a  continual  basis.  There  is  no  better 
way  to  improve  process  performance  in  meeting  the 
needs  of  all  stakeholders  in  the  process. 
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9.4.6  Prepare  Regular  Operating  Status 
Reports.  Finally,  process  management  requires  an 
effective  system  of  communicating  status  reports 
related  to  process  performance.  In  the  industrial 
age  enterprise,  status  reports  were  generated  at  the 
front  line  and  flowed  upward  through  successive 
(sometimes  excessive)  layers  of  management.  In 
the  information  age  enterprise,  status  reports  flow 
horizontally  so  that  everyone  (especially  front-line 
workers)  have  the  information  they  need  to  provide 
superior  performance.  The  concept  of  worker 
empowerment  demands  this  type  of  information 
sharing.  Local  area  networks,  client/server  systems, 
e-mail,  bulletin  board  services,  and  other  emerging 
technologies  provide  the  means  to  effect  this 
horizontal  flow  of  information. 

In  well-designed  processes,  control  points 
exist  to  provide  upper  management  with  the  specific 
data  and  information  they  need  to  do  their  jobs. 

This  lessens  the  need  to  spend  non-value  added  time 
preparing  and  communicating  routine  status  data. 
Once  the  routine  is  eliminated,  upward  status 
reporting  can  be  restricted  to  the  exceptional  which 
helps  ensure  quick  action  on  those  situations 
requiring  upper  management  involvement. 

This  concludes  the  operate  and  maintain 
process  and  information  systems  step. 

9.5  Step  25:  Conduct  Continuous  Process 

Improvement  Program 

Process  management,  as  described  in  the 
previous  step,  is  concerned  with  maintaining  the 
gains  produced  by  a  business  process  improvement 
effort.  The  emphasis  is  on  preventing  the  newly 
redesigned  process  from  deteriorating  or  degrading 
over  time.  In  this  context,  process  management  is 
reactive.  That  is,  it  is  waiting  for  indicators  to 
suggest  that  there  is  a  problem  or  issue,  then 
responding  to  the  threat  to  process  performance  that 
problem  or  issue  suggests. 


Many  enterprises  are  going  beyond  basic 
process  management  by  putting  a  proactive  Total 
Quality  Management  (TQM)  program  in  place. 
TQM  makes  Continuous  Process  Improvement 
(CPI)  an  organizational  mandate  and  the  primary 
responsibility  of  all  management  levels.  TQM 
doesn’t  wait  for  problems  to  occur,  it  actively  seeks 
to  avoid  problems  from  occurring  in  the  first  place. 

TQM  is  not  a  methodology  and  as  such 
doesn’t  have  a  life  cycle  like  business  process 
reengineering.  It  is  actually  a  system  of  leadership 
and  management  that  leads  to  the  establishment  of  a 
culture  of  excellence  and  superlative  performance, 
especially  with  respect  to  anticipating  and 
responding  to  customer  needs.  Business  Process 
Reengineering  (BPR)  attempts  to  recognize  and 
satisfy  all  stakeholder  interests,  TQM  is  customer 
driven.  BPR  strives  for  immediate  and  dramatic 
improvements  in  process  performance,  TQM  strives 
for  long  range  and  continuous  improvements  with  a 
focus  on  establishing  and  maintaining  excellent 
customer  relationships. 

The  principal  features  of  a  well-developed 
TQM  program  include  the  following:^' 

■  Management  leadership,  commitment, 
and  participation.  In  a  TQM 
environment,  aU  levels  of  management 
are  actively  engaged  in  process 
management  and  improvement. 
Employees  have  access  to  leaders  and 
managers,  there  is  a  free  flow  of 
information  in  both  directions,  and 
leaders  are  visible. 

■  Participation  of  all  functions  of  the 
organization.  In  a  TQM  environment, 
there  are  no  turf  issues  or  power  plays. 
Everyone  understands  that  they  are  there 
to  serve  customers.  Problems  and  issues 
are  avoided  or  resolved  in  a  cooperative 
fashion.  While  responsibility  and 


31  Process  Management,  Eugene  H.  Melon,  McGraw-Hill,  1993,  Chapter  10. 
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accountability  are  required,  blame  is  not 
assessed  and  punishment  is  not  the  order 
of  the  day  when  things  go  wrong. 

Employee  commitment  and  involvement. 
In  a  TQM  environment,  employees  are 
involved  in  the  process  and  encouraged 
to  take  risks  to  improve  the  organization, 
its  products,  and  its  customer  service. 
Team  work  is  stressed,  and  employees 
are  motivated  to  share  their  knowledge 
and  experience  with  others.  The 
organization  understands  that  it  is  there 
to  support  front-line  workers  who  build 
products,  provide  services,  and  satisfy 
customers. 

Customer  orientation.  In  a  TQM 
environment,  it  is  understood  that  the 
purpose  of  the  organization  is  to  serve 
customer  needs,  requirements,  and 
desires.  In  the  context  of  mission,  and 
with  respect  to  all  stakeholders,  the 
process  is  optimized  to  serve  customers. 
Wherever  possible,  guidelines  replace 
rules,  empowerment  to  act  replaces 
passing  the  buck,  and  employees  make 
the  extra  effort  to  help  their  customers 
and  clients. 

A  system  for  continuous  improvement.  In 
a  TQM  environment,  improvement  is  the 
order  of  the  day.  Techniques  are 
available  to  gather  and  analyze 
performance  data  so  that  improvements 
can  be  quantified  and  tracked. 

Employees  are  trained  to  anticipate 
problems  and  empowered  to  do 
something  constructive  about  them. 

Ideas  and  best  practices  are  freely  shared 
throughout  the  organization. 

A  means  for  assessing  progress.  In  a 
TQM  environment,  control  points  and 
measures  are  built  in  to  processes  so  that 
process  performance  can  be  tracked  in 
real  time.  Employees  have  access  to 
performance  data  as  it  becomes  available 
and  trained  on  what  to  do  with  this  data. 
There  is  a  linkage  between  planning  and 


production  systems  so  that  everyone  in 
the  organization  can  assess  progress  to 
plan. 

■  Education  arui  training.  In  a  TQM 
environment,  training  is  continuous 
whether  conducted  by  formal  or  informal 
means.  The  enterprise  strives  to  be  a 
learning  organization  where  problems 
are  solved  once  and  lessons-Ieamed 
shared.  Mistakes  are  considered 
opportunities  for  learning,  not  cause  for 
punishment.  Skill  development  is 
stressed  so  that  employees  are  as  flexible 
as  possible  in  their  work  assignments, 
and  comfortable  with  changes  in  work 
processes  and  technology. 

■  Rewards  and  recognition.  In  a  TQM 
environment,  employees  are  recognized 
and  rewarded  on  individual  skill 
development  and  cooperative  team  work 
in  pursuit  of  process  objectives.  Skill 
development  leads  to  a  more  flexible 
work  force  and  conditions  employees  to 
be  more  receptive  (less  fearful)  of 
change.  Team  performance  is  the  most 
productive  means  of  rewarding 
accomplishment  because  it  discourages 
turf  battles  and  personal  aggrandizement. 

■  Communication.  In  a  TQM 
environment,  people  communicate  freely 
with  each  other.  Information  is  a 
resource  to  be  shared  rather  than 
hoarded.  Fear,  uncertainty,  and  doubt  is 
overcome  by  the  free  exchange  of 
information  about  policy,  plans,  and 
performance.  Technology  is  employed  to 
maximize  horizontal  communications 
which  leads  to  empowerment  and  more 
effective  team  work. 

■  Strategy  and  deployment.  In  a  TQM 
environment,  strategy  is  developed  by 
senior  leadership  in  a  cross-functional 
manner  and  then  deployed  throughout 
the  organization  level-by- level.  Every 
strategy  is  decomposed  until  an  action 
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plan  is  developed  which  will  help  realize 
the  strategy.  Performance  measures  are 
linked  to  strategy  to  ensure  that  process 
and  organizational  performance  can  be 
tested  against  plans. 

■  Supplier  relationships.  In  a  TQM 
environment,  suppliers  are  considered  to 
be  partners  in  the  pursuit  of  satisfying 
customer  needs,  requirements,  and 
desires.  Suppliers  understand  what  is 
expected  of  Aem  and  take  responsibility 
for  delivering  high-quality  data  and 
materials  at  the  time  they’re  needed,  and 
at  or  below  the  agreed  upon  cost 
estimate. 

In  summary,  in  a  TQM  environment,  there  is  a 
definite  customer  orientation  and  focus  that 
conditions  the  actions  of  employees  within  the 
context  of  satisfying  all  stakeholder  interests. 
Human  resource  excellence  is  a  business  objective 
since  employees  are  considered  to  be  the  most 
important  asset  in  the  enterprise.  Management  is 
based  on  proven  leadership  principles  and 
management  actions  are  focused  on  continuously 
increasing  the  effectiveness  and  productivity  of 
employees.  Organization  stmctures  are  in  place  to 
optimize  process  performance.  Processes  have 
owners  who  strive  to  break  through  functional 
barriers  in  pursuit  of  process  excellence. 
Information  systems  are  engineered  to  enable  and 
support  well-designed  processes. 

The  following  tasks  are  performed  in  the 
conduct  continuous  process  improvement  program 
step: 

■  Review  Performance/Status/Problem 
Reports 

■  Conduct  Surveys/Interviews/ 
Questionnaires/Focus  Groups 

■  Monitor  Stakeholder  Feedback 

■  Identify  Incremental  Improvement 
Opportunities 


■  Design  Incremental  Change 
Specifications 

■  Implement  Incremental  Change  Program 

■  Prepare  Regular  Improvement  Status 
Reports 

9.5.1  Review  Performance/Status/Problem 
Reports.  Active  process  management  results  in  a 
continuous  stream  of  ideas,  suggestions, 
compliments,  complaints,  problem  reports,  and 
people-related  issues.  These  data  are  supplemented 
by  a  stream  of  performance  measurement  data.  In 
an  organization  practicing  TQM,  each  of  these 
artifacts  and  measures  of  process  operations  is 
given  serious  attention  by  employee  work  teams. 
The  more  difficult  situations  are  brought  to 
management’s  attention  by  the  employees 
themselves.  This  is  an  important  concept.  In  a 
traditional  organization,  managers  bring  problems 
to  the  attention  of  employees.  That  a  TQM  culture 
is  well-established  is  self-evident  when  employees 
take  the  initiative  to  bring  problems  to  the  attention 
of  management. 

When  policy  deployment  is  practiced  in  an 
organization,  each  employee  has  a  list  of  daily  or 
routine  objectives  and  responsibilities  complete 
with  performance  indicators.  Daily  management 
requires  effective  management  of  routine  processes, 
discovering  abnormalities  or  deviations,  and 
preventing  their  recurrence.^^  This  means  that 
problem  determination  and  reporting  is  or  becomes 
a  routine  job  performance  task. 

Problem  reports,  status  reports,  and 
measurement  data  is  a  resource  that  can  be  used  to 
drive  continuous  process  improvement  efforts.  This 
is  more  likely  to  happen  when  employees 
themselves  are  responsible  for  improvement  efforts. 
In  the  traditional  authoritarian  environment, 
problems  and  issues  tend  to  be  hidden  or  suppressed 
until  they  become  so  large  that  they  cannot  escape 
the  attention  of  management. 


32  Total  Quality  Control  Essentials,  Sarv  Singh  Soin,  McGraw-Hill,  1992,  Page  74. 
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9.5.2  Conduct  Surveys/Interviews/ 
Questionnaires/Focus  Groups.  Since  customers 
are  the  focus  of  continuous  process  improvement 
efforts,  it  is  necessary  to  maintain  frequent  and  open 
communications  with  customers.  Work  teams  are 
empowered  to  conduct  periodic  customer 
satisfaction  surveys,  interview  selected  customers, 
and  hold  focus  groups  when  indicated.  Problem 
reports,  complaints,  and  even  compliments 
associated  with  customers  can  indicate  a  need  to 
solicit  the  voice  of  the  customer. 

The  industrial  age  is  best  characterized  by  a 
quote  attributed  to  Henry  Ford:  A  customer  can 
have  any  color  car  he  wants  as  long  as  it  is  black. 
Most  government  enterprises  have  moved  very  little 
from  that  attitude.  The  information  age  is  best 
characterized  by  Alvin  Toffler  in  The  Third  Wave: 
...completely  customized  goods  [and  services] 
produced  with  wholistic  continuous-flow  processes, 
increasingly  under  the  direct  control  of  the 
consumer.^^  This  means  that  it  is  an  imperative  to 
stay  close  to  customers  and  ensure  that  their  needs 
and  desires  are  recognized  and  acted  upon.  This  is 
especially  true  in  government  enterprises  because 
they  have  lagged  so  far  behind  the  private  sector  in 
their  treatment  of  customers.  This  is  evidenced  by 
competition  in  public  domain  services,  the  move  to 
outsourcing,  and  privatization  actions  in  recent 
years. 

The  way  to  stay  close  to  customers  is  to  meet 
with  them,  listen  to  them,  and  form  partnerships  to 
design,  maintain,  and  improve  high-performance 
processes.  The  challenge  for  government 
enterprises  is  to  move  from  a  rule-based  culture  to  a 
service-based  culture  while  maintaining  equity  and 
fairness.  It  can  be  done  and  it  has  been  done  in  the 
public  sector. 

9.5.3  Monitor  Stakeholder  Feedback.  Like  all 
enterprises,  government  must  satisfy  multiple 
stakeholders.  The  Framework  methodology 
recognizes  five  classes  of  stakeholders: 


■  Customers.  Customers  are  the  recipient 
of  products  and  services  produced  by 
processes.  However,  customers  of 
government  services  are  more  like  clients 
than  consumers.  Unlike  consumers  in 
the  private  sector,  clients  of  government 
services  are  often  unwilling  customers. 
For  instance  prisoners  are  unwilling 
consumers  of  penal  system  services. 
Nevertheless,  customers  have  a  voice 
and  feedback  should  be  solicited  from 
them  as  it  appropriate  to  do  so. 

■  Suppliers.  Suppliers  provide  goods, 
services,  and  data  that  are  consumed  in 
government  processes  to  produce 
required  outputs.  Government  must 
strive  to  move  from  an  adversarial 
relationship  with  their  suppliers  to  more 
of  a  partnership  relationship.  The 
information  age  both  demands  this  and  at 
the  same  time  provides  the  means  to 
accomplish  the  objective.  Government 
enterprises  have  much  to  gain  by 
listening  to  feedback  provided  by  key 
suppliers. 

■  Higher  Authority.  Higher  authority  is 
any  entity  that  imposes  rules,  constraints, 
standards,  or  requirements  on 
government  processes.  Congress  acts  as 
higher  authority  to  most  Federal 
processes.  Higher  authority,  like  all 
stakeholders,  has  an  interest  in  process 
performance.  The  move  to  reinvent 
government  is  largely  concerned  with 
changing  the  relationship  of  higher 
authority  to  the  processes  it  affects. 

Rules,  regulation,  and  public  laws  are 
now  being  subject  to  review,  revision,  or 
rescission.  But  in  the  move  to  free  up 
processes  from  unwarranted  controls,  it 
is  important  to  understand  higher 
authority’s  intent  and  interests. 


33  The  Third  Wave,  Alvin  Toffler,  William  Morrow  and  Company,  1980,  Page  202. 
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■  Resource  Providers.  Resource  providers 
are  any  entity  that  fuels  processes. 
Taxpayers  and  citizens  act  as  resource 
providers  for  most  Federal  processes. 

The  fuel  may  be  funds,  machines, 
facilities,  contracts,  or  labor  hours. 

These  stakeholders  have  a  voice  also  that 
should  be  listened  to  while  engaged  in 
continuous  process  improvement. 

■  Process  Participants.  Process 
participants  are  the  employees  and 
managers  that  perform  business 
processes.  Quality  of  worklife,  rewards 
and  recognition,  skill  development,  and 
pride  of  accomplishment  are  some  of  the 
interests  process  participants  have  in 
process  performance.  Since  it  is  difficult 
to  satisfy  other  stakeholders  if  process 
participants  are  dissatisfied,  it  is  most 
important  to  listen  to  their  voice  as 
continuous  process  improvement 
proceeds. 

9.5.4  Identify  Incremental  Improvement 
Opportunities.  The  results  produced  by  the  first 
three  tasks  in  this  step  provide  the  raw  material  for 
identifying  improvement  opportunities.  In  a  TQM 
environment,  those  improvements  that  can  be  acted 
upon  without  the  need  to  establish  a  formal  process 
reengineering  or  redesign  effort  are  called 
incremental  improvements.  Employee  work  teams 
identify,  classify,  prioritize,  and  characterize 
improvement  opportunities.  These  are  often  the 
subject  of  regular  management/staff  meetings  or 
regularly  scheduled  quality  improvement  efforts. 

Work  teams  employ  many  of  the  techniques 
described  in  section  10  of  this  guidebook  to  gather 
and  analyze  performance  and  decision  data  related 
to  improvement  possibilities.  The  use  of  techniques 
and  tools  removes  the  subjectivity  sometimes 
associated  with  incremental  improvements,  and 
builds  confidence  with  management  that  the  work 
team  knows  what  it  is  doing  and  is  acting  on  the 
basis  of  facts. 

The  routine  work  of  gathering  improvement 
opportunity  data  is  often  supplemented  by  support 


resources  that  evaluate  the  worth  (benefits)  of  the 
improvement  opportunity  and  estimate  the  time  and 
resources  needed  to  implement. 

9.5.5  Design  Incremental  Change  Specifications. 

When  an  improvement  opportunity  is  reviewed  and 
approved,  it  becomes  necessary  to  design  the 
changes  that  will  be  necessary  to  implement. 
Incremental  improvements  most  often  affect  work 
flows  and  activities  rather  than  organizational 
structure  or  information  systems  support.  They 
usually  also  have  limited  cross-functional 
implications  and  seldom  require  a  capital 
investment.  Nevertheless,  there  is  still  the  need  to 
engage  in  a  limited  design  effort  to  minimize  the 
chance  of  disruptions  to  process  performance  or 
customer  service. 

The  design  effort  for  implementing 
incremental  improvements  depends  to  a  large  extent 
on  the  availability  of  accurate  and  up-to-date 
process-related  documentation.  This  is  why 
document  maintenance  is  emphasized  in  the  process 
management  step.  All  proposed  design  changes 
should  be  reflected  in  the  documentation  to 
maintain  its  accuracy  and  usefulness. 

9.5.6  Implement  Incremental  Change  Program. 

Implementation  should  be  staged  to  minimize 
normal  process  operations.  Following 
implementation,  a  test  plan  should  be  executed  to 
ensure  that  no  errors  have  been  inadvertently 
introduced  into  the  process,  its  products,  or  its 
services.  Process  owners  should  be  actively 
involved  in  all  implementation  efforts  especially 
those  that  have  cross-functional  implications. 

In  some  cases,  the  regular  work  team  will 
implement  incremental  improvements,  in  other 
cases,  a  special  task  team  will  be  formed  to 
accomplish  this.  It  is  often  helpful  to  have  an 
outside  facilitator  or  consultant  review  the 
implementation  process.  It  may  also  be  useful  to 
include  a  customer  and/or  supplier  representative  to 
provide  a  check  and  balance  arrangement. 

9.5.7  Prepare  Regular  Improvement  Status 
Reports.  A  characteristic  feature  of  a  TQM 
environment  is  the  persistent  effort  to  evaluate  and 
assess  process  performance  with  respect  to 
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Stakeholder  interests.  While  the  specific  nature  of 
status  reporting  is  dependent  on  the  characteristics 
of  the  process,  the  following  categories  of  data  may 
be  included  in  a  system  of  regular  status  reporting: 

■  Customer  complaints,  comments,  and 
compliments 

■  Instances  of  inconsistent  output  quality 

■  Absence  of  taking  corrective  actions 
indicated  in  previous  reports 

■  Lack  of  interest  in  or  knowledge  of 
customer  situations 

■  Overly  long  problem  response  time  as 
indicated  by  performance  measures 

■  The  existence  of  too  many  verification  or 
inspection  activities 

■  Evidence  of  redundant,  unnecessary,  or 
non-value  added  activities 

■  Too  much  rework  or  corrective  activities 

■  Excessive  costs  associated  with  value 
added  activities  suggesting  the  need  for 
information  systems  support 

■  Incoming  material  quality  and  timeliness 

■  Quality,  availability,  and  features  of 
machines,  equipment  and  tools 

■  Defects  in  technical  designs  and  lack  of 
supporting  data 

■  Skill  level  deficiencies  or  lack  of  labor 
resources 


Whatever  the  format  of  the  status  report,  it 
should  have  these  features: 

■  The  specific  problem  is  defined  and 
characterized 

■  Performance  data  related  to  the  problem 
is  gathered,  analyzed,  and  summarized 

■  There  is  a  recommendation  on  the  course 
of  action  to  be  taken 

■  Evidence  of  accountability  has  been 
established  and  a  suspense  record  has 
been  created 

■  There  are  follow-up  reports  of  previously 
reported  problems. 

In  summary,  in  a  TQM  environment,  there  is  a 
continuous  insertion  of  energy  into  all  business 
processes  to  improve  process  performance  and 
satisfy  stakeholder  interests  in  an  optimal  fashion. 
Employees,  especially  front-line  employees,  are 
empowered  to  act  individually  and  as  teams.  This 
empowerment  is  established  by  a  continuous 
education  and  training  program  backed  up  by  an 
engaged  management  following  established  and 
proven  leadership  principles. 

This  concludes  the  execution  phase  of  the 
Framework  methodology. 


Management-related  issues 


9-30 


Project  Execution-  (Rev.  5.3:  15  DEC  94) 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


SECTION  10.  TECHNIQUES  FOR  PROCESS  IMPROVEMENT 


There  is  a  saying:  if  all  you  have  is  a  hammer, 
everything  looks  like  a  nail.  Process  improvement 
teams  need  a  complete  repertoire  of  techniques  and 
tools  for  the  same  reason  a  carpenter  needs  a  full 
complement  of  tools.  Whether  building  processes 
or  houses,  tools  in  the  hands  of  skilled  craftsmen 
can  produce  a  much  better  product. 

In  this  guidebook,  the  term  technique  means  a 
method  or  procedure  for  gathering,  analyzing,  or 
displaying  data  or  information.  The  term  tool  refers 
to  an  automated  system  for  implementing  a 
technique.  The  term  product  refers  to  a  specific  or 
commercial  tool.  For  instance,  feramjtorniing  is  a 
technique,  groupware  is  a  system  that  automates  the 
brainstorming  technique.  Lotus  Notes  is  a 
commercial  groupware  system.  In  the  literature,  the 
terms  tools  and  techniques  are  often  used 
interchangeably.  This  is  not  terribly  important  as 
long  as  the  reader  knows  the  context  in  which  the 
terms  are  used. 

This  section  of  the  guidebook  will  briefly 
describe  over  25  techniques  that  can  be  used  in 
support  of  process  improvement  efforts.  The 
presentation  of  each  technique  will  be  brief  because 
the  only  way  to  really  imderstand  a  technique  is  to 
actually  use  it.  One  can  no  more  learn  how  to  use  a 
technique  by  reading  about  it  than  one  can  learn  to 
ride  a  bike  by  reading  about  it.  Eventually,  you  just 
have  to  mount  up  and  tide. 

The  objective  is  not  to  use  techniques  for  their 
own  sake.  Ilie  purpose  of  having  techniques  is  so 
that  process  improvement  teams  can  base  their 
decisions  on  objective  data  rather  than  subjective 
feelings.  By  using  techniques  to  support  process 
improvement 

recommendations  and  designs,  teams  will  be  better 
positioned  to  overcome  barriers  and  obstacles  to 
improvement,  and  will  more  readily  secure  approval 
from  higher  authority  to  proceed  with  improvement 
efforts. 

This  section  is  not  meant  to  be  all-inclusive  of 
process  improvement  techniques.  There  are  other 
techniques  that  have  proved  useful  in  process 


improvement,  and  readers  may  want  to  check  the 
references  listed  in  appendix  B  for  other  techniques. 

The  following  subsections  contain  lists  of 
techniques  that  conform  to  the  requirements 
specified  in  the  subsection.  In  each  case,  the 
techniques  are  listed  in  the  same  sequence  that  they 
are  described  in  section  10.3. 

10.1  Technique  Modes 

For  convenience,  we  group  techniques  into 
four  categories — ^graphical,  statistical,  modeling, 
and  textual.  Each  category  is  useful  for  specific 
purposes  at  different  points  in  the  Framework 
methodology.  Familiarity  with  the  techniques,  and 
experience  in  their  use  will  help  teams  know  when, 
where,  and  why  to  select  one  category  of  technique 
over  another.  Some  techniques  may  fit  into  two  or 
more  categories. 

10.1.1  Graphical.  Graphical  techniques  are  best 
used  when  it  is  necessary  to  display  the 
relationships  between  or  among  entities.  These 
relationships  can  show  order  or  sequence,  priorities, 
dependencies,  groupings  and  categories,  and 
physical  positioning.  The  following  are  graphical 
techniques: 

■  Quality  Function  Deployment  (QFD) 

■  Process  flow  and  process  deployment 

■  Affinity  diagramming 

■  Relationship  diagramming 

■  Pareto  analysis 

■  Force  field  analysis 

■  Program  Decision  Process  Chart  (PDPC) 

■  Program  Evaluation  and  Review 
Technique  (PERT) 

■  Gantt  charts 

■  Checksheets 

■  Cause  and  Effect  charts. 

Graphical  techniques  are  highly  useful  for 
communicating  ideas  to  interested  parties  outside  of 
the  process  improvement  team.  Whenever  possible, 
data  should  be  displayed  in  the  form  of  graphics. 
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10.1.2  Statistical.  Statistical  techniques  are  used 
to  gather  and  analyze  data  resulting  from  repetitive 
processes.  Statistical  techniques  should  only  be 
used  when  there  is  enough  data  available  (enough 
data  points)  to  make  the  results  meaningful.  The 
use  of  most  statistical  techniques  requires 
specialized  training  in  the  science  of  statistics, 
heuristics,  and  probability  theory.  The  following 
are  statistical  techniques: 

■  Histograms 

■  Simulation 

■  Control  charts. 

10.1.3  Modeling.  Models  are  highly  structured 
graphics  with  a  specialized  syntax  designed  to 
convey  graphical  information  with  a  high  degree  of 
precision.  Many  modeling  techniques  are  precise 
enough  to  be  supported  with  automated  tools  that 
can  draw  the  models  and  transfer  meaningful  data  to 
dictionaries,  directories,  repositories,  and  other 
software  systems.  Modeling  techniques  are  used  to 
gather,  an^yze,  and  display  data.  The  following  are 
modeling  techniques: 

■  Process  flow  and  process  deployment 

■  Activity  modeling 

■  Data  modeling 

■  Simulation. 

10.1.4  Text-based.  Text-based  techniques  include 
narratives,  reports,  tables,  matrices,  and  numeric 
representations.  They  are  often  used  to  supplement 
the  results  obtained  from  using  other  techniques.  In 
general,  the  more  structured  the  data  recorded  with 
the  use  of  text-based  techniques,  the  more  useful 
and  maintainable  the  data.  Even  data  presented  in 
report  form  should  follow  a  well-developed  content 
outline  and  be  supplemented  wherever  possible  with 
graphs,  charts,  models,  and  tables.  The  following 
are  text-based  techniques: 

■  Brainstorming 

■  Nominal  Group  Technique  (NGT) 

■  Performance  cell 

■  Strategic  benchmarking 

■  Strength,  Weakness,  Threat,  Opportunity 
(SWOT)  analysis 

■  Hoshin  planning 

■  Activity-based  Costing  (ABC) 


■  Best  practices  benchmarking 

■  Economic  analysis 

■  Survey/interview. 

10.2  Technique  Application 

Techniques  should  be  used  to  accomplish 
predetermined  objectives.  That  is,  select  a 
technique  for  a  specific  purpose  and  ensure  that  the 
purpose  is  fulfilled.  Otherwise,  process 
improvement  teams  can  get  carried  away  with  the 
use  techniques  and  end  up  more  confused  than 
when  they  started.  The  following  subsections  are 
designed  to  suggest  applications  for  techniques. 

10.2.1  Consensus  Building.  Process  improvement 
is  usually  accomplished  by  cross-functional  teams 
working  together.  At  the  conclusion  of  every  step  in 
the  methodology,  there  should  be  team  consensus 
on  the  results  obtained,  the  meaning  of  those  results, 
and  the  application  of  the  results  in  subsequent 
steps.  The  use  of  techniques  puts  process 
improvement  in  objective,  rather  than  subjective 
terms.  The  more  objective  the  results,  the  easier  it 
is  to  gain  consensus  because  emotional  or  irrational 
elements  are  minimized.  By  consensus,  we  mean 
understanding,  agreement,  harmony  and  unanimity. 
Consensus  is  the  basis  for  effective  decision 
making. 

Process  improvement  also  results  in  the 
development  of  in-process  reports  that  have  to  be 
reviewed  and  approved  before  improvement  efforts 
can  continue.  This  means  that  the  improvement 
team  must  gain  consensus  with  review  teams  and 
higher  authorities.  Techniques  can  aid  this  process 
by  displaying  data  in  terms  that  can  be  easily 
understood  by  those  who  are  not  working  day-to- 
day  on  the  improvement  team.  Almost  all  of  the 
techniques  presented  in  this  section  can  be  used  to 
gain  consensus  both  within  the  improvement  team 
and  with  outside  elements. 

The  first  step  in  gaining  consensus  is  to  get  all 
of  the  facts,  ideas,  opinions,  concerns,  issues, 
barriers,  and  objections  out  in  the  open  so  that  they 
can  be  dealt  with  in  an  objective  manner.  The 
following  techniques  are  particularly  effective  in 
this: 
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■  Brainstorming 

■  Nominal  Group  Technique 

■  SWOT  analysis 

■  Hoshin  planning 

■  Force  field  analysis 

■  PDPC 

■  Survey/interview 

■  Cause  and  Effect  analysis. 

The  second  step  in  gaining  consensus  is  to 
display  or  present  data  in  a  form  that  makes  it  easy 
to  either  agree  on  a  set  of  data  or  point  out  areas  of 
disagreement  that  can  be  further  investigated.  In 
addition  to  the  techniques  listed  in  the  above 
subsection,  modeling  techniques  can  be  used  to 
display  data  in  a  way  that  helps  resolve  areas  of 
disagreement. 

10.2.2  Data  Gathering.  The  more  useful  the  data 
that  are  gathered  in  support  of  process  improvement 
efforts,  the  more  effective  process  improvement 
efforts  will  be.  For  meaningful  process 
improvement,  data  must  be  gathered  about  the 
process  in  question  (baseline  data);  from  all 
interested  parties  (stakeholders)  especially  their 
needs,  requirements,  and  desires;  about  the 
environment  the  process  operates  in  (organizational 
and  technological  infrastmcture);  and  about  the 
possibilities  for  improvement. 

There  will  always  be  more  data  available  than 
the  process  improvement  team  can  hope  to  gather 
and  analyze.  This  means  that  the  data  gathering 
process  must  be  disciplined  and  structured.  Before 
any  data  is  gathered,  the  team  must  be  able  to 
answer  the  following  questions  (who,  what,  when, 
where,  why,  how,  and  how  much:) 

■  What  data  do  we  need 

■  Why  do  we  need  it 

■  When  do  we  need  it  (what  step  in  the 
methodology) 

■  What  filters  will  we  use  to  screen  out 
unneeded  data 

■  What  will  we  do  with  the  data  when  we 
get  it 

■  What  are  the  best  sources  for  the  data 

■  Why  are  they  the  best  sources 

■  Who  do  we  need  to  talk  to 


■  How  much  time  will  we  allocate  to  data 
gathering 

■  What  do  we  need  to  look  at  (investigate) 

■  What  is  the  best  means  (technique)  of 
getting  the  data 

■  Who  will  do  the  data  gathering 

■  What  do  they  need  to  know  before  they 
start? 

Planning  the  data  gathering  effort  is  most 
important.  The  plan  should  be  written  and 
evaluated  before  the  data  gathering  effort  starts.  For 
instance,  a  good  benchmarking  effort  can  take  three 
to  six  months  and  cost  several  thousands  of  dollars 
to  conduct.  The  team  should  be  certain  of  their 
objective  before  they  commit  the  time  and  expense 
of  using  this  technique.  The  following  techniques 
are  the  ones  most  useful  for  data  gathering: 

■  Brainstorming 

■  Performance  cell 

■  Strategic  benchmarking 

■  QFD 

■  SWOT 

■  Best  practices  benchmarking 

■  Economic  analysis 

■  Survey/interview 

■  Checksheets 

■  Control  charts. 

10.2.3  Data  Analysis.  Raw  data  is  seldom  useful. 
All  the  data  that  is  worth  gathering  is  worth 
analyzing  to  derive  meaning  (information)  from  the 
data.  Ineffective  data  analysis  is  more  than 
worthless,  it  is  misleading  and  damaging.  The 
adage:  there  are  lies,  damn  lies,  and  statistics 
points  out  that  we  can  analyze  data  in  such  a  way  as 
to  support  any  predetermined  conclusion  if  we  so 
choose.  To  minimize  or  prevent  this  from 
happening,  data  analysis  must  be  as  disciplined  and 
structured  as  the  data  gathering  process  that 
produced  the  data. 

In  data  analysis,  it  is  important  to  select  the 
most  effective  technique  for  the  job  at  hand,  use  the 
technique  properly,  and  then  let  the  results  speak  for 
themselves.  If  there  are  disagreements  in  the 
interpretation  of  the  results,  rather  than  rework  the 
analysis,  it  is  better  to  note  the  differences  in  a 
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supplemental  report.  In  this  way,  others  can 
examine  the  results  without  bias. 

The  following  techniques  are  the  ones  most 
useful  for  data  analysis.  There  are  many  techniques 
that  can  be  used  for  data  analysis,  so  it  is  most 
important  to  select  the  ones  most  appropriate  for  the 
task  at  hand.  Experience  in  using  the  techniques 
will  provide  skill  in  technique  selection.  Some  of 
the  techniques  listed  are  also  used  in  data  gathering. 
In  other  words,  the  technique  is  used  to  both  collect 
and  organize  data.  In  this  case,  the  results  are  more 
suspect  because  the  person  or  team  using  the 
technique  may  have  lost  some  objectivity  in  the 
analysis  phase  of  the  technique: 

■  Nominal  Group  Technique 

■  Strategic  benchmarking  (analysis, 
conclusions,  and  recommendations) 

■  QFD 

■  Affinity  diagram 

■  Relationship  diagram 

■  Activity  modeling 

■  Data  modeling 

■  Activity-based  costing 

■  Pareto  analysis 

■  Histograms 

■  Best  practices  benchmarking 

■  Simulation 

■  Force  field  analysis 

■  Economic  analysis 

■  PDPC 

■  PERT 

■  Control  charts. 

■  Cause  and  Effect. 

10.2.4  Decision-support.  Most  of  the  techniques 
covered  in  this  section  are  designed  for  use  by  the 
process  improvement  team.  Some,  however,  are 
quite  useful  for  presenting  data  to  review  teams  and 
higher  authorities  to  aid  in  decision  making  with 
respect  to  some  phase  of  the  improvement  project. 

It  is  important  that  when  a  technique  is  used  to 
generate  decision-support  data,  the  data  itself  is 
neutral,  balanced,  and  factual.  It  is  proper  to 
recommend  a  course  of  action,  but  the  decision 
making  team  must  have  access  to  all  of  the  data  that 
lead  to  a  recommendation  for  one  course  of  action 
and  the  rejection  of  other  alternatives. 


Decision-support  data  should  be  concise  and 
focused.  The  techniques  used  to  develop  decision- 
support  reports  will  generally  produce  far  more  data 
than  should  be  presented  to  the  decision  making 
agency.  This  so-called  backup  should  be  organized 
and  preserved  should  it  be  needed  to  justify  the 
recommended  course  of  action.  It  should  not, 
however,  be  part  of  the  original  submittal  except  in 
summary  form.  The  following  techniques  are 
effective  for  developing  decision-support  materials. 
A  key  decision-support  factor  is  noted  for  each 
technique  listed: 

■  Nominal  Group  Technique  (rank/ 
prioritize  alternatives) 

■  Performance  cell  (acceptance  of 
performance  targets) 

■  Hoshin  planning  (acceptance  of 
performance  objectives) 

■  Activity — modeling  TO-BE  situation 
(proposed  future  state) 

■  Data  modeling — TO-BE  situation 
(proposed  future  state) 

■  ABC  (acceptance  of  unit  cost  values) 

■  Force  field  analysis  (acceptance  of 
barriers  to  progress) 

■  Economic  analysis  (implementation 
alternatives) 

■  PERT  (acceptance  of  schedules  and 
costs) 

■  Cause  and  Effect  (acceptance  of  drivers). 

10.2.5  Presentation.  Techniques  provide  an 
effective  means  of  developing  materials  for 
presenting  progress,  results,  plans,  proposals, 
scenarios,  and  other  aspects  of  an  improvement 
project.  The  following  techniques  are  most  often 
used  to  develop  presentation  aids.  In  most  cases, 
the  presentation  materials  are  a  by-product  of 
technique  use,  not  the  main  purpose  for  using  the 
technique: 

■  Performance  cell 

■  QFD  (high-level  matrices  only) 

■  Hoshin  planning  (cascading  objectives) 

■  Process  flow,  process  deployment 

■  Activity  models  (context  and  node  trees 
only) 

■  Data  models  (entity/relationship  only) 

■  Pareto  charts 
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■  Histograms 

■  Gantt  charts 

■  Check  sheets 

■  Cause  and  Effect  (simplified  for 
presentation). 

10.3  Technique  Descriptions 

The  objective  of  this  section  is  to  present  a 
brief  description  of  some  of  the  techniques  that  have 
proved  usefol  in  support  of  process  improvement 
efforts.  The  purpose  is  to  make  process 
improvement  team  members  aware  of  the  range  of 
techniques  that  are  available. 

The  techniques  presented  in  this  section  are 
organized  by  general  purpose  with  respect  to 
process  improvement  efforts.  Strategic  techniques 
are  the  ones  most  useful  for  supporting  planning 
efforts,  developing  performance  measures  and 
targets,  process  visioning,  and  conceptual 
relationships  within  the  organizational  unit. 

Tactical  techniques  are  most  often  used  to  discover 
or  understand  process  improvement  opportunities, 
and  to  develop  process  improvement  initiatives  and 
alternatives.  Operational  techniques  are  most  often 
used  on  a  continuing  basis  to  monitor  process 
performance,  support  continuous  improvement 
efforts,  and  solve  process-related  problems.  This  is 
meant  as  a  guide,  not  to  suggest  that  technique  use 
is  in  any  way  restricted.  The  techniques  described 
below  may  be  used  together  in  any  combination 
anywhere  in  the  25-step  methodology.  The 
classification  of  techniques  into  strategic,  tactical, 
and  operational  is  only  for  convenience  in 
describing  them,  and  to  suggest  their  most  prevalent 
use. 

10.3.1  Strategic  Techniques.  The  first  phases  of  a 
process  improvement  project  are  concerned  with 
preparing  for  process  improvement  efforts.  It  is 
during  the  planning  phase  that  process  improvement 
teams  need  to  understand  their  objectives  and 
challenges.  The  techniques  described  in  this 
subsection  have  proved  most  useful  for  supporting 
planning  efforts,  and  discovering  and  describing 
problems  and  opportunities. 


10.3.1.1  Brainstorming.  Brainstorming  is  one  of 
the  most  widely  used  process  improvement 
techniques.  It  is  acmally  a  disciplined  form  of 
creative  thinking.  The  idea  behind  brainstorming  is 
to  use  the  mind’s  power  of  association.  Given  one 
idea  on  a  particular  subject,  the  mind  can  often 
come  up  with  related  ideas.  In  a  group  situation 
with  7  to  15  people,  each  idea  offered  up  stimulates 
others  to  come  up  with  their  own  related  ideas. 
Brainstorming  is  aided  by  a  facilitator  who  provides 
the  structure  for  a  brainstorming  session  and 
ensures  wide  participation  from  the  group. 

Brainstorming  can  be  performed  in  a 
conference  or  classroom  with  whiteboards  or 
wallcharts,  or  it  can  be  performed  using  groupware 
facilities.  Groupware  is  the  generic  name  for  a 
system  of  networked  personal  computers  with 
special  software  and  projection  capability.  Rather 
than  call  out  their  ideas  with  the  facilitator  writing 
them  on  a  board,  participants  enter  their  ideas 
directly  into  a  personal  computer.  Among  other 
services,  the  software  system  collates  all  the  ideas 
entered  into  the  system. 

The  general  rules  for  brainstorming  are  the 
following: 

■  Ideas  submitted  by  participants  are  not 
filtered  or  judged.  This  permits  a  free 
flow  of  ideas,  some  of  which  might  be 
useful,  some  not. 

■  During  the  idea  generation  phase,  there  is 
no  discussion  on  the  ideas.  Discussion 
would  interrupt  the  flow  and  nullify  one 
of  the  important  advantages  of  this 
technique. 

■  Ideas  are  recorded  as  submitted.  This  is 
a  moot  point  if  groupware  facilities  are 
used. 

■  Continue  with  the  session  until  all  ideas 
are  exhausted.  Sometimes  a  brief  rest 
break  will  lead  to  further  ideas  on  the 
topic  under  study. 


Techniques  for  Process  Improvement  -  (Rev.  5.3:  15  DEC  94) 


10-5 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


Among  its  other  benefits,  brainstorming, 
because  of  its  fast  pace,  often  uncovers  obstacles 
and  barriers  to  a  planned  course  of  action  that 
otherwise  might  stay  hidden  for  some  time. 

10.3.1^  Nominal  Group  Technique  (NGT). 

NGT  is  a  structured  group  activity  that  can  be  used 
to  evaluate  and  rank  a  series  of  actions  or  activities 
concerning  the  development  of  a  plan  or  program  to 
resolve  an  issue.  Often  NGT  techniques  are  used 
after  a  brainstorming  session  to  organize,  evaluate, 
and  rank  the  ideas  developed  by  the  group.  The 
concept  is  similar  to  brainstorming.  The  synergy  of 
the  group  is  applied  to  the  problem  at  hand.  The 
power  of  this  technique  is  that  all  members  of  the 
team  get  an  equal  voice  in  selecting  an  idea  or 
action  item. 

The  general  rules  for  using  nominal  group 
technique  are  the  following: 

■  The  facilitator  states  the  problem  to  be 
solved,  or  the  nature  of  the  decision  to  be 
made  by  the  group. 

■  Ideas  are  generated  or  brought  over  from 
the  brainstorming  session. 

■  In  a  round-robin  situation,  each  team 
member,  in  turn,  presents  an  idea  related 
to  the  problem  at  hand.  The  facilitator 
continues  around  the  group  until  all  ideas 
are  exhausted. 

■  The  group  then  discusses  the  ideas  on  the 
board  or  screen  and  clarifies, 
consolidates,  and  groups  them  into 
related  categories. 

■  The  group  develops  the  criteria  that  will 
be  used  to  judge  and  rank-order  the 
ideas. 

■  Each  team  member  then  selects  from  five 
to  eight  of  the  ideas  or  actions  from  the 
list  of  all  ideas  or  actions.  These 
represent  that  team  member’s 
preferences.  The  team  member  then 
ranks  those  selected  ideas  or  actions 
from  one  to  five  (or  eight)  with  the  most 


preferred  item  getting  the  highest 
number. 

■  The  facilitator  then  counts  the  votes  cast 
for  each  of  the  items  on  the  list.  The 
item  getting  the  most  votes  represents  the 
consensus  opinion  of  the  group.  It  is 
usually  advisable  to  discuss  the  results 
and  ensure  that  the  selected  ideas  or 
actions  really  are  what  the  group  wants. 

It  may  be  necessary  to  take  another  vote 
on  a  shortened  list  of  items  that  got  the 
most  votes  in  the  first  round. 

10.3.1.3  Performance  cell  technique.  The 
Performance  Cell  Technique  (PCT)  is  designed  to 
provide  a  bridge  that  links  business  planning, 
process  identification,  and  process  improvement. 
Once  established  in  an  organization,  PCT  provides 
critical  performance  data  (baseline  and  target)  that 
together  with  business  planning  improvement 
objectives  functions  as  a  charter  for  process 
improvement  action  teams.  PCT  also  establishes  a 
basis  for  calculating  the  Return  On  Process 
Improvement  (ROPI)  equations.  ROPI  is  a 
technique  for  estimating  and  measuring  the 
improvement  in  process  value  as  a  result  of  a 
potential  or  actual  process  improvement  action  or 
project. 

PCT  is  designed  to  support  the  objectives  and 
principles  in  the  Government  Performance  and 
Results  Act  by  providing  a  technique  to  quantify 
performance  indicators  for  efficiency  and 
effectiveness  relating  to  any  given  process,  conduct 
performance  gap  analysis,  and  deliver  coherent 
improvement  goals  and  targets  to  process 
improvement  teams  at  the  start  of  an  improvement 
project.  In  this  way,  a  clear  connection  between 
strategic  planning  objectives  and  process 
performance  can  be  established,  maintained,  and 
monitored.  Improvement  efforts  will  be  directly 
related  to  strategic  and  business  planning 
objectives.  Performance  indicators  will  be 
established  that  help  ensure  that  the  gains  made 
through  process  improvement  efforts  will  be  held, 
beginning  when  the  new  process  is  deployed  and 
becomes  operational. 
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PCT  also  helps  ensure  that  process 
improvement  efforts  are  optimized  for  all  process 
objectives  including  cycle  time,  process  cost,  and 
quality  such  that  the  needs  of  all  process 
stakeholders  are  taken  into  account.  When 
compromises  must  be  made,  PCT  provides  an 
objective  means  of  developing  criteria  for  decision¬ 
making  purposes.  For  more  information  on  this 
technique,  refer  to  the  Performance  Cell  'Ritorial 
which  is  part  of  the  Framework  methodology  series 
of  documents. 

10.3.1.4  Strategic  benchmarking.  Strategic 
benchmarking  is  a  continuous,  systematic  and 
analytical  process  for  evaluating  and  assessing  the 
business  practices,  operations,  and  functions  of 
organizations  that  are  recognized  as  best-in-class  for 
the  purpose  of  establishing  priorities,  targets,  and 
goals.^  Benchmarking  is  most  often  used  during 
the  strategic  and  business  planning  phases  to  aid  in 
developing  long-  as  well  as  short-term  plans,  goals 
and  objectives.  Benchmarking  teams  typically 
examine  from  five  to  twelve  enterprises  that  share 
several  characteristics  with  their  own  organization. 
A  benchmarking  team  will  examine: 

■  Finished  goods,  products,  and  service 
features 

■  How  products  and  services  are  produced 
and  supported 

■  Supporting  functions  such  as 
administration,  personnel,  and  finance 

■  Measures  such  as  cost,  cycle  time,  and 
quality 

■  Strategies,  plans,  goals  and  objectives. 

The  benchmarking  process  most 
recommended  is  the  one  developed  by  Xerox 
Corporation  who  is  generally  credited  with 
formalizing  the  concept. 

The  following  are  the  usual  steps  in 
benchmarking: 

■  Determine  what  to  benchmark  and  define 
the  purpose  of  the  study 

■  Form  and  train  a  benchmarking  team 


■  Identify  benchmark  partners  and 
establish  the  basis  for  the  study 

■  Collect  and  analyze  all  data  gathered 
from  benchmark  partners 

■  Produce  a  benchmarking  report  with 
conclusions  and  recommendations. 

10.3.1.5  Quality  Function  Deployment.  Quality 
Function  Deployment  (QFD)  is  a  systematic 
approach  to  determining  and  understanding 
customer  requirements  for  products  and  services, 
and  then  translating  those  requirements  into 
specifications  for  developing  and  delivering  the 
desired  products  and  services.  QFD  is  based  on  a 
system  of  interlocking  matrices  that  can  be 
customized,  as  needed,  to  suit  the  types  of  products 
and  services  in  question.  From  one  to  44  matrices 
are  developed  depending  on  how  elaborate  and 
detailed  the  design  team  wishes  to  get. 

Typically,  marketing,  service,  engineering, 
procurement,  and  production  people  work  together 
and  with  customers  to  develop  and  refine  the 
matrices.  QFD  can  answer  the  following  questions: 

■  What  do  customers  really  want  or  desire 
from  our  products  and  services 

■  What  are  the  priorities  in  their  wants  and 
desires 

■  How  well  do  competitors  or  alternative 
sources  meet  these  requirements 

■  What  product  and  service  features  will 
meet  customer  requirements 

■  Will  any  product  design  features  conflict 
with  or  reinforce  other  features 

■  What  processes  are  needed  to  produce 
product  and  service  features? 

The  first  QFD  matrix  is  often  called  the  house 
of  quality  or  the  voice  of  the  customer  hecaase  its 
primary  function  is  to  determine  real  customer 
needs.  In  some  cases,  especially  with  services,  this 
is  the  only  matrix  needed  by  the  improvement  team. 
This  matrix  maps  customer  wants  with  product 
features.  The  second  matrix  maps  product  features 
with  required  product  components.  The  third 
matrix  maps  product  components  with  the  processes 


34  The  Benchmarking  Book,  Michael  J.  Spendolini,  Amacom,  1992. 


Techniques  for  Process  Improvement  -  (Rev.  5.3:  15  DEC  94) 


10-7 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


required  to  produce  them.  The  fourth  matrix  maps 
processes  to  finished  products  and  services. 
Therefore,  there  is  a  causal  chain  developed  from 
final  product  back  to  customer  demand.  Additional 
matrices  are  for  highly  specialized  analysis  and 
usually  only  applicable  to  highly  engineered 
products. 

QFD  helps  ensure  that  all  efforts  by  the 
organization  are  the  direct  result  of  understanding 
what  has  to  be  done  to  satisfy  customer  needs, 
wants,  desires,  requirements,  and  expectations. 
Conversely,  QFD  helps  an  organization  discover 
and  eliminate  all  those  activities  that  do  not  directly 
contribute  to  fulfilling  customer  requirements.  For 
further  information  on  QFD,  check  the  bibliography 
in  appendix  B,  or  refer  to  “House  of  Quality,”  John 
R.  Hauser  and  Don  Clausing,  Harvard  Business 
Review,  May-June  1988,  pp  63-73. 

10.3.1.6  StrengthAVeakness/Opportunity/Threat 
(SWOT)  analysis.  SWOT  analysis  is  a  systematic 
approach  to  understanding  the  organization,  its 
products  and  services,  and  its  processes  in  terms  of 
the  internal  and  external  environment  in  which  it 
operates.  SWOT  analysis  is  generally  conducted  as 
part  of  the  strategic  planning  process,  although  it 
may  be  effectively  used  at  various  times  in  the  25- 
step  methodology  to  stimulate  creatively  and  idea 
generation. 

SWOT  analysis  is  best  conducted  by  a  cross¬ 
functional  team  with  the  aid  of  a  facilitator  who  acts 
as  a  neutral  party  during  the  procedure.  The  team 
attempts  to  develop  a  list  of  dl  of  the  organizational 
strengths  and  weatoesses  related  to  the  topic  of 
discussion.  For  instance,  If  the  topic  is  a  process 
under  an  improvement  study,  the  team  lists  all  of  the 
process’s  strengths  and  weaknesses  with  respect  to 
customer  service  requirements,  competitive  sources, 
or  best-in-class  as  determined  during  a 
benchmarking  study.  Next,  the  team  tries  to 
discover  all  of  the  threats  to  attaining  process 
success  as  defined  during  business  planning  or 
described  in  performance  cells.  Finally,  the  team 
tries  to  uncover  all  the  opportunities  for  excellence 
that  can  be  achieved  by  overcoming  threats. 


maximizing  process  strengths,  and  minimizing 
process  weaknesses. 

10.3.1.7  Hoshin  planning.  Hoshin  planning,  or 
Hoshin  Kanri  and  Nichijo  Kami  to  be  precise, 
originated  at  the  Bridgestone  Tire  Company  in 
Japan  in  the  1960s^^  Since  then,  virtually  all  large 
Japanese,  and  many  American  companies  have 
adopted  these  techniques  with  good  results.  Hoshin 
Kanri  (which  means  control  of  objectives)  is  a  more 
effective  form  of  management  by  objectives  (MBO), 
and  is  actually  based  on  military  planning  methods. 
We  recommend  using  a  modified  form  of  Hoshin 
Kanri  for  the  improvement  division  of  the  annual 
plan  (see  section  4). 

Nichijo  Kanri  (which  means  daily 
management)  is  a  form  of  management  by  critical 
success  factor  or  by  key  indicator.  We  recommend 
using  a  modified  form  of  Nichijo  Kami  for  the 
operations  division  of  the  annual  plan. 

The  following  terms  with  their  precise 
definitions  are  used  in  Hoshin  planning: 

■  Objective:  An  objective  is  a  desired  end 
result  or  condition  expressed  in 
measurable  terms  that  can  be  achieved 
by  the  successful  performance  of  one  or 
more  business  or  functional  processes. 

■  Goal:  A  goal  (or  target)  is  the  criterion 
by  which  you  measure  the 
accomplishment  of  an  objective.  Every 
objective  must  have  a  quantifiable  goal 
or  target. 

■  Strategy:  A  strategy  is  a  method  or 
procedure  for  accomplishing  the  related 
objective  and  achieving  the  desired  goal. 

■  Performance  Measure:  A  performance 
measure  is  an  indicator  built  in  to  a 
strategy  that  can  measure  progress 
toward  satisfying  the  related  strategy. 


35  Total  Quality  Control  Essentials,  Sarv  Singh  Soin,  McGraw-Hill,  New  York  (1992),  Chapter  3. 
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■  Critical  Success  Factor  ( CSF):  A  CSF  is 
a  business  function  or  activity  that  must 
be  performed  correctly  and  completely. 

■  Key  Indicator:  A  key  indicator  is  a 
measurement  that  is  readily  obtained  by 
observation  of  a  business  process  or 
activity  which  provides  data  on  how  well 
a  process  or  activity  is  performing. 

■  Variance  or  limits:  The  degree  to  which 
a  key  indicator  can  vary  and  still  be 
within  tolerance. 

With  Hoshin  planning,  there  is  a  series  of 
cascading,  interlocked  objectives  that  provides 
direct  links  between  strategic  objectives  and 
specific  action  plans.  The  concept  is  that  when  the 
lowest  level  objectives  are  satisfied,  the  higher  level 
objective  is  automatically  satisfied,  and  so  on  up  the 
chain  of  objectives.  For  more  information  of  this 
technique,  refer  to  the  Planning  Tiitorial  which  is 
part  of  the  Framework  methodology  series  of 
documents. 

10.3.1.8  Process  flow/deployment  A  process 
flowchart  is  a  high-level  representation  of  the  major 
activities,  inputs  and  outputs,  and  decision  points  in 
a  process.  It  is  produced  by  a  cross-functional  work 
team  in  the  initial  stages  of  an  improvement  project. 
It  is  generally  produced  on  a  wallchart  that  is 
displayed  for  the  duration  of  the  improvement 
project.  The  wallchart  can  be  effectively  used  to 
launch  an  activity  modeling  session.  The  value  of 
the  process  flow  diagram  is  that  it  shows  the  big- 
picture  of  a  process,  is  quickly  produced,  is  highly 
visible,  and  (unlike  more  rigorous  techniques  like 
IDEF)  the  method  to  create  it  is  non-threatening  to 
functional  persons.  The  process  flow  diagram  is 
usually  produced  once  customer  requirements  are 
known  either  through  a  planning  session, 
brainstorming  session,  or  after  using  QFD 
techniques. 

The  diagram  begins  with  the  inputs  to  the 
process  and  ends  with  the  desired  outputs.  Three 
questions  are  asked  as  each  element  of  the  process 
flow  diagram  between  the  inputs  and  the  outputs  is 
produced: 


■  What  is  the  activity  (what  is  done  to  the 
input) 

■  What  customer  requirement  does  it 
satisfy  (why  are  we  doing  it) 

■  What  decisions  are  made  during  the 
activity? 

A  process  deployment  diagram  is  similar  to  a 
process  flow  diagram  except  in  it,  each  activity  of 
the  process  is  mapped  to  the  organizational  unit  that 
is  responsible  for  the  activity.  In  other  words,  the 
deployment  diagram  adds  responsibility  to  the 
process  flow  diagram.  This  is  most  helpful  as  the 
first  step  in  setting  the  scope  of  a  process 
improvement  project  and  determining  the 
composition  of  the  cross-functional  team  that  will 
work  on  the  project.  This  mapping  is  usually  done 
by  listing  the  organizational  units  at  the  top  of  the 
wallchart,  and  aligning  activities  under  the  unit  as 
appropriate. 

Both  process  flow  and  process  deployment 
diagrams  are  quite  useful  for  verifying  the  workings 
of  a  process  with  outside  stakeholders,  especially 
customers.  This  is  because  the  wallchart  is  easily 
understood  by  persons  who  may  not  be  familiar 
with  more  complex  modeling  methods  such  as 
IDEF.  Verification  by  stakeholders  is  exceedingly 
important  before  process  improvement  continues  to 
ensure  that  the  process  improvement  team  does  not 
lose  sight  of  why  they  are  improving  the  process — 
to  better  serve  stakeholder  interests. 

10.3.1.9  Affinity  diagram.  Affinity  diagramming 
(also  known  as  Ae  KJ  method™  after  its  creator, 
Kawakita  Jiro)  is  the  organized,  consolidated  output 
resulting  from  a  brainstorming  session  in  which 
large  amounts  of  data  have  been  generated.  It  is 
used  when  the  issues  being  investigated  are 
numerous  and  complex,  and  the  thoughts  on  how  to 
deal  with  the  issue  are  in  disarray.  In  using  this 
technique,  individual  ideas  or  items  are  grouped 
under  a  common  header  that  best  summarizes  or 
consolidates  those  ideas  or  items.  In  this  way,  a 
great  many  items  can  be  reduced  to  a  smaller 
number  of  related  groups.  The  groups  then  become 
the  basis  for  an  action  plan  or  an  approach  to 
solving  a  problem. 
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The  technique  is  performed  by  a  facilitated 
improvement  team,  working  at  different  times 
individually,  in  small  groups,  and  all  together.  The 
process  is  best  performed  using  wallcharts  (or 
whiteboards)  and  index  cards  (or  yellow  stickles). 
The  process  is  creative,  yet  disciplined  and  is  quite 
effective.  The  following  steps  are  performed: 

■  State  the  issue  or  topic 

■  Brainstorm  for  ideas  writing  each  idea  on 
a  card  or  stickle 

■  Distribute  the  cards  to  the  group  or 
subgroups 

■  Group  the  cards  by  categories  or 
common  characteristics 

■  Discuss  the  groupings 

■  Title  each  grouping  and  revise  as 
necessary 

■  Draw  a  wallchart  that  sequences  the 
grouping  and  lists  the  items  that  make  up 
each  group. 

10.3.1.10  Relationship  diagram.  Relationship 
diagrams  are  simple  representations  of  cause  and 
effect  with  respect  to  a  given  problem  or  process. 

In  a  relationship  diagram,  each  element  of  a  process 
or  problem  is  written  inside  a  circle  or  rectangle  on 
a  wallchart.  The  circles  themselves  are  usually 
arranged  in  a  larger  circle.  Starting  at  the  one- 
o’clock  position,  the  question  is  asked  of  the  item  at 
that  location:  what  other  items  are  related  to  this 
item  and  what  is  the  nature  of  the  relationship? 

The  relationship  is  expressed  by  drawing  a 
line  between  the  two  items.  If  the  item  at  the  one- 
o’clock  position  is  the  driver,  cause,  influencer  of, 
or  takes  precedence  over,  the  other  item  (say  the 
item  at  two-o’clock),  an  arrowhead  is  placed  on  the 
two-o’clock  item.  If  the  relationship  is  the  reverse, 
the  arrowhead  is  place  on  the  item  at  the  one- 
o’clock  position.  In  the  example  below,  providing 
materials  takes  precedence  over  using  the  materials 
to  construct  something.  If  the  problem  being  solved 
has  to  do  with  the  quality  of  the  birdhouse,  the 
diagram  suggests  that  first  the  quality  of  the 
materials  should  be  checked. 


Figure  10-1.  Relationship  Diagram 


Each  item  on  the  wallchart  is  examined  in  the 
same  way  until  all  arrows  with  the  arrowheads  in 
the  proper  position  have  been  drawn.  There  will  be 
zero  to  many  arrows  pointing  in  to  each  item,  and 
zero  to  many  items  pointing  out  of  each  item.  If  an 
item  has  no  arrows,  the  item  is  removed  from 
further  consideration.  The  item  with  the  most 
arrows  leaving  is  the  most  independent  of  all  the 
items  on  the  chart.  It  may  be  the  root  cause  of 
every  other  item.  The  item  with  the  most  arrows 
pointing  into  it  is  the  most  dependent  item.  It  may 
be  the  root  effect  of  the  problem  or  process. 

Usually,  all  improvement  efforts  should  be 
directed  at  the  root  causes  of  a  problem  or  process 
non-performance  issue.  The  items  that  are  root 
effects  can  serve  as  validators  since  if  the  root 
causes  are  corrected,  the  root  effects  should  go 
away  or  cease  to  be  a  problem.  Besides  identifying 
root  causes,  this  technique  can  also  be  used  to 
prioritize  efforts  based  on  those  items  (problems  or 
activities)  that  have  the  most  arrows  leaving  them. 

10.3.2  Tactical  Techniques.  Techniques  in  this 
category  are  the  ones  most  often  used  specifically 
for  process  analysis.  Strategic  techniques  focus  on 
discovering  or  defining  problems  and  opportunities, 
while  tactical  techniques  focus  on  solving  problems 
and  exploiting  opportunities. 

10.3.2.1  Activity  modeling.^  A  model  is  a 
representation  of  a  set  of  components  of  a  system, 
subject  area,  or  process.  The  model  is  developed 


36  See  Integration  Definition  for  Function  Modeling  (IDEFO),  FIPS  Pub  183,  December  21,  1993.  Material  for  this 
subsection  was  extracted  from  this  publication. 
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for  understanding,  analysis,  improvement,  or 
replacement  of  the  system  or  process.  The  model 
describes  what  a  system  or  process  does,  what 
controls  it,  what  things  it  works  on,  what  means  it 
uses  to  perform  its  functions  or  activities,  and  what 
it  produces. 

An  activity  model  is  composed  of  a 
hierarchical  series  of  diagrams  that  gradually 
display  increasing  levels  of  detail  describing 
functions  or  activities  and  their  interfaces.  Models 
provide  a  blueprint  of  activities  and  their  interfaces 
that  must  be  understood  in  order  to  make  process 
improvement  decisions  that  are  logical,  affordable, 
integratable,  and  achievable. 

Activity  modeling  is  used  to; 

■  Perform  analysis  and  design  at  all  levels 
of  the  process 

■  Produce  reference  documentation  as  a 
basis  for  process  improvement  and 
integration 

■  Communicate  among  analysts,  designers, 
users,  and  managers 

■  Facilitate  consensus  among  cross¬ 
functional  teams 

■  Manage  large  and  complex  projects 
using  qualitative  measures  of  progress 

■  Provide  a  reference  architecture  for 
enterprise  analysis,  information 
engineering  and  resource  management. 

The  basic  concepts  embodied  in  activity 
modeling  include  the  following: 

■  Graphic  representation  of  activities  and 
the  interactions  among  activities 

■  Conciseness 

■  Communication 

■  Rigor  and  precision 


■  Step-by-step  procedures 

■  Functional  vs  Organizational  viewpoint. 

10.3.2.2  Data  modeling.^’  Data  modeling  is  used 
to  produce  a  graphical  information  model  that 
represents  the  stmcture  and  semantics  of 
information  within  an  environment,  system,  or 
process.  Use  of  a  standard  modeling  technique 
permits  the  construction  of  semantic  data  models 
that  may  serve  to  support  management  of  data  as  a 
resource,  the  integration  of  information  systems, 
and  the  building  of  computer  databases.  The 
purpose  of  the  modeling  technique  is  to  produce 
models  in  a  standard,  consistent,  predictable  manner 
in  order  to  manage  data  as  a  resource.  The 
modeling  standard  provides  a: 

■  Means  for  understanding  and  analyzing 
an  organization’s  data  resources 

■  Common  means  of  representing  and 
communicating  the  complexity  of  data 

■  Method  for  presenting  an  overall  view  of 
the  data  required  to  ran  an  enterprise 

■  Means  for  defining  an  application- 
independent  view  of  data  that  can  be 
validated  by  users  and  transformed  into  a 
physical  database  design 

■  Method  for  deriving  an  integrated  data 
definition  from  existing  data  resources. 

Data  models  are  comprised  of  entities  that 
represent  persons,  places,  things,  concepts,  ideas, 
and  events  that  are  related  to  the  process.  The 
entities  are  graphically  shown  with  their  attributes 
(data  items),  keys  (data  identifiers),  and  their 
relationships  to  other  entities. 

Data  modeling  performed  by  a  cross¬ 
functional  process  improvement  team  is  usually 
limited  to  identifying  the  entities,  primary  keys, 
major  attributes  and  business  rales  associated  with 


37  See  Integration  Definition  for  Function  Modeling  (IDEFIX),  FIPS  Pub  184,  December  21,  1993.  Material  for 
this  subsection  was  extracted  from  this  publication. 
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the  process  under  improvement.  Data  models  are 
then  turned  over  to  data  administration  and 
technical  support  where  they  are  fully  developed  so 
that  they  can  be  used  to  drive  database  development 
and  information  system  integration.  In  this  way 
data  modeling  provides  a  common  means  of 
communication  between  functional  and  technical 
elements  with  respect  to  database  development. 

10.3.2.3  Activity-Based  Costing  (ABC).  ABC  is  a 
technique  used  to  determine  the  cost  elements 
needed  to  produce  a  given  product  or  service.  By 
identifying  these  cost  elements,  it  becomes  possible 
to  determine  the  unit  cost  of  every  major  output 
produced  by  a  process.  As  part  of  ABC  analysis, 
activities  are  evaluated  in  terms  of  whether  they  add 
value  or  don’t  add  value  to  the  output  product  or 
service.  When  this  information  is  known,  process 
improvement  efforts  can  be  directed  to  minimizing 
or  eliminating  non- value  added  costs  and  activities 
from  the  process. 

ABC  analysis  also  includes  the  concept  of 
tracing  activity  costs  back  to  the  point  in  the  process 
where  the  given  cost  is  triggered.  This  enables  the 
improvement  team  to  focus  on  cost-drivers  (the  root 
cause  of  the  cost)  rather  than  at  the  point  in  the 
process  where  the  cost  is  felt.  For  instance,  in  a 
given  process,  if  maintenance  costs  for  product  x 
are  considered  to  be  too  high,  the  cause  of  the 
maintenance  problem  may  be  that  defective  (low 
quality)  materials  were  procured  earlier  in  the 
process  to  build  the  product.  The  way  to  reduce 
maintenance  costs  is  not  to  improve  maintenance 
activities  on  product  x,  but  rather  to  improve  the 
quality  of  the  materials  used  to  build  product  x. 

This  will  result  in  lower  maintenance  costs  on  the 
product. 

ABC  analysis  is  facilitated  by  first  producing 
an  activity  model  of  the  process  being  studied. 

With  a  fully  decomposed  activity  model,  it  becomes 
relatively  easy  to  research  financial  data,  develop 
unit  costs,  locate  non-value  added  activities,  and 
find  cost-drivers.  ABC  analysis  is  most  effective  in 
manufacturing  processes,  but  has  been  found  useful 
in  service-based  processes  as  well. 


10.3.2.4  Pareto  analysis.  A  Pareto  diagram  is  a 
simple  bar  chart  that  graphically  illustrates  the 
components  of  a  problem  or  proposed  solution  in 
decreasing  order  of  occurrence  or  importance.  With 
Pareto  analysis,  improvement  teams  can  focus  on 
the  important  few  rather  than  the  trivial  many  when 
dealing  with  a  problem  or  opportunity.  This 
technique  is  the  practical  application  of  the  80-20 
rule  which  states  that  in  any  given  situation  with 
multiple  casual  elements,  80%  of  the  problem  or 
situation  is  embodied  in  20%  of  the  constituent 
elements. 

Pareto  analysis  is  used  to  arrange  data  into 
categories  that  can  be  time,  location,  component, 
person,  type,  etc.,  and  then  graphically  ranking  the 
number  of  occurrences  in  each  category  over  a 
given  period  of  time.  Before  Pareto  auialysis  can  be 
used,  data  related  to  the  situation  must  be  collected. 
Checksheets  (described  later)  are  the  most  common 
technique  for  collecting  data  for  Pareto  analysis. 

In  the  Pareto  diagram  below  representing  a 
process  problem,  categories  1  and  2  cause  most 
problem  occurrences  and  should  be  the  focus  of  the 
process  improvement  team’s  efforts.  In  this 
example,  there  are  a  total  of  260  occvirrences,  and 
categories  1  and  2  account  for  170  (about  70%)  of 
the  occurrences. 

Process  improvement  teams  may  be  reluctant 
to  use  Pareto  analysis  because  it  is  so  simple. 
However,  there  are  many  uses  of  the  Pareto  diagram 
and  one  effective  use  is  for  management 
presentations.  In  practice,  after  Pareto  analysis 
produces  the  trivial  few  categories  of  problems  to 
be  solved,  cause  and  effect  analysis  (described  later) 
can  be  used  to  find  the  root  causes. 

10.3.2.5  Histograms.  A  histogram  is  another  type 
of  bar  chart.  A  histogram  represents  and  displays 
the  frequency  of  occurrence  of  classes  of  data.  The 
resulting  diagram  is  used  for  further  analysis, 
usually  of  a  statistical  nature.  Histograms  can 
display  central  tendencies  (mean,  median,  and 
mode),  width  and  range  of  occurrences  (standard 
deviation),  and  shape.  Histograms,  therefore,  tell  a 
lot  about  the  operation  of  a  system  which  can  be 
used  to  improve  the  system.  This  technique  is 
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Figure  10-2.  Pareto  Diagram 

usually  used  to  determine  the  baseline  condition  or  can  be  subjected  to  histogram  analysis  to  determine 
situation  of  a  process  or  system,  and  to  validate  or  whether  the  improvement  objective  was 
verify  the  results  of  an  improvement  effort.  accomplished. 

For  instance,  if  a  given  process  is  operating  at  10.3.2.6  Best  practices  benchmarking.  Best 
a  quality  level  of  3  defects  per  100  opportunities  practices  is  one  of  several  forms  of  benchmarking, 

and  the  goal  is  to  achieve  3  defects  per  1000;  data  The  intent,  as  it  is  with  all  benchmarking,  is  to  leam 

collected  before  and  after  the  improvement  project  from  other  organizations  and  apply  what  was 
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learned  to  bettering  the  organization.  There  are  six 
basic  steps  to  process  benchmarking:^® 

■  Plan:  Understand  and  measure 

critical  success  factors 

■  Search:  Research  appropriate 

organizations  for  process 
comparison 

■  Observe:  Monitor  process  performance 

and  analyze  performance  gaps 

■  Analyze:  Determine  the  root  cause  of 

the  performance  gap 

■  Adapt:  Select  best  practices  and 

modify  for  company 
environment 

■  Improve:  Enhance  and  integrate 

business  process 
improvements. 

10.3.2.7  Simulation.®’  Simulation  is  the  use  of  a 
model  to  conduct  experiments.  The  model,  which 
changes  over  time,  conveys  an  understanding  of  the 
system  being  represented.  The  purpose  of 
experimenting  using  simulation  is  to  solve  problems 
by  discovering  something  unknown  or  testing 
theoretical  solutions  to  problems.  The  results  of  the 
experiment  are  then  used  to  make  prudent  decisions. 

Simulation  is  a  tool  that  characterizes  a 
problem,  and  provides  a  means  for  evaluating 
potential  solutions.  Since  there  are  usually  many 
possible  solutions  for  every  problem,  finding 
potential  solutions  requires  a  thorough 
understanding  of  what  constitutes  the  problem. 

This  understanding  is  accomplished  by  collecting 
and  analyzing  data  pertaining  to  the  issue. 

Candidate  solutions  are  then  designed  based  upon 
this  data  and  tested  in  the  simulation  environment. 


Simulation: 

■  Can  promote  creativity  and  zest  for 
trying  new  ideas 

■  Can  predict  outcomes  for  various  courses 
of  actions 

■  Can  account  for  the  effects  of  variances 
occurring  in  a  system 

■  Promotes  total  solutions 

■  Brings  expertise,  knowledge,  and 
information  together 

■  Can  be  cost  effective  in  terms  of  time. 

Simulation  addresses  aspects  of  processes  for 
which  activity  and  data  modeling  are  not  suited. 
Since  activity  and  data  models  are  static,  they 
cannot  cope  with  the  impact  of  resource  flow.  Such 
impacts  include  bottlenecks,  underutilization  of 
resources,  and  distribution  anomalies.  In  summary, 
simulation  is  a  useful  technique  to  supplement  and 
enhance  the  value  of  activity  and  data  modeling  and 
activity-based  costing. 

10.3.2.8  Force  field  analysis.  The  concept  of  force 
field  analysis  is  that  any  problem  or  situation  is  a 
result  of  Ae  forces  acting  upon  it.  There  are  two 
general  types  of  forces  involved  restraining  forces 
and  driving  forces.  Driving  forces  are  those  that  are 
trying  to  cause  a  change  in  a  static  condition. 
Restraining  forces  are  those  that  are  trying  to 
maintain  the  static  condition.  When  attempting 
change  or  improvement,  if  the  restraining  and 
driving  forces  can  be  understood,  the  process 
improvement  team  can  look  for  ways  to  enhance  the 
driving  forces  and  moderate  the  restraining  forces. 

Force  field  analysis  uses  a  graphical  technique 
to  map  the  forces  that  are  affecting  situation.  All  of 
the  restraining  forces  are  shown  on  one  side  of  a 
horizontal  line  that  represents  the  current  situation, 
and  all  of  the  driving  forces  are  shown  on  the  other 
side.  In  the  example  shown  below,  the 
improvement  team  wants  to  drive  down  the  defect 
rate  in  a  process.  The  forces  that  are  restraining  this 
effort  are  shown  below  the  simation  line,  and  the 
forces  that  are  driving  this  effort  are  shown  above. 


38  The  Benchmarking  Workbook,  Gregory  H.  Watson,  Productivity  Press,  Cambridge,  1992. 

39  This  subsection  was  extracted  from  the  Functional  Process  Simulation  Guidebook,  ANSER,  December,  1993. 
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Driving  Forces 

Current  Situation 

i 

Too  Many  Defects 

1 

Restraining  Forces 

Figure  10>3.  Force  Field  Diagram 


One  driving  force  may  be  customer  complaints, 
another,  management  imperative.  A  restraining 
force  may  be  poorly  maintained  equipment. 

Once  all  of  the  forces  are  mapped,  it  becomes 
possible  to  see  how  opposing  forces  line  up  and 
then  look  for  ways  to  counter  forces  against  each 
other  so  that  the  current  situation  moves  in  the 
direction  of  the  desired  improvement.  Force  field 
analysis  is  particularly  valuable  in  investigating 
organizational  change  management  issues  including 
the  very  familiar  resistance  to  change  syndrome 
which  is  a  restraining  force.  A  driving  force  that 
could  counter  the  resistance  to  change  force  might 
be  a  change  in  employee  incentives  If  the 
incentives  are  sufficient,  resistance  to  change  will 
be  overcome. 

Force  field  analysis  works  very  well  with 
cause  and  effect  analysis  (described  later),  which 
can  be  used  to  determine  the  root  cause  of  both 
restraining  and  driving  forces.  For  instance,  the 
improvement  team  may  want  to  use  cause  and  effect 
analysis  to  determine  the  source  for  the  restraining 
force — ^resistance  to  change.  Once  the  causes  are 
known,  cause  and  effect  analysis  can  again  be  used 
to  determine  exactly  what  kind  of  incentive  package 
(driving  force)  it  would  take  to  overcome  this 
restraining  force. 

10.3.2.9  Economic  Analysis.  Economic  analysis  is 
a  structured  technique  that  can  be  used  to  identify 
alternative  solutions  to  a  given  problem,  and  then 


select  the  most  cost-effective  alternative.  Economic 
analysis  uses  a  simple  six  step  process. 

1 .  State  the  problem  to  be  solved  or  the 
desired  accomplishment  in  non-biased, 
objective  terms. 

2.  State  the  assumptions  and  constraints 
that  form  the  boundary  conditions  for 
developing  alternative  solutions. 
Assumptions  are  explicit  statements  (but 
not  facts)  used  to  describe  the  present 
and  future  environment  upon  which  the 
economic  analysis  is  based.  Constraints 
are  factors  external  to  the  environment 
that  limit  the  number  of  alternatives 
which  can  be  developed. 

3.  List  all  of  the  alternative  solutions  for  the 
defined  problem.  Alternatives  take  the 
form  of  make  v  buy,  buy  v  lease,  repair  v 
replace,  automation  v  manual,  and 
change  v  status  quo. 

4.  List  all  of  the  costs  and  benefits  for  each 
alternative.  Benefits  must  be  stated  in 
quantifiable  (measurable)  terms  although 
not  necessarily  monetary  terms. 

5.  Compare  alternatives  in  terms  of  their 
costs  and  benefits  in  net  present  value 
terms.  Usually,  software  algorithms  are 
used  to  automate  this  procedure. 
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6.  Adjust  alternative  solutions  for  risk  and 
sensitivity.  Risk  analysis  takes  into 
account  die  uncertainty  of  future  results 
based  on  present  actions.  Sensitivity 
analysis  is  a  method  of  compensating  for 
the  uncertainty  of  the  assumptions  upon 
which  the  choice  of  alternatives  were 
made. 

10.3.2.10  Program  Decision  Process  Chart  (risk 
analysis).  Program  Decision  Process  Charts 
(PDPC)  are  used  to  develop  contingency  plans  for 
proposed  courses  of  action.  Every  course  of  action 
(including  improvement  actions)  carries  with  it  the 
risk  of  failure.  If  it  didn’t,  it  would  probably  have 
already  been  done. 

The  starting  point  for  using  this  technique  is  to 
identity  the  elements  of  an  improvement  program  or 
action  plan.  Often,  affinity  or  relationship  diagrams 
can  be  used  for  this  purpose.  Each  component  in 
the  action  plan  is  written  on  a  wallchart.  For  each 
action,  a  process  improvement  team  brainstorms  all 
of  the  things  that  could  possibly  go  wrong  in  trying 
to  carry  out  the  indicated  course  of  action.  These 
are  noted  in  a  tree-shaped  diagram,  usually  shown 
horizontally  rather  than  vertically. 

For  each  potential  problem,  the  team  then 
develops  potential  countermeasures  that  can  be  used 
to  overcome  each  barrier.  When  countermeasures 
have  been  developed  for  each  potential  roadblock  or 
problem,  the  team  then  evaluates  the  probability  of 
each  problem  occurring,  the  severity  of  the  resulting 
situation,  and  the  most  effective  response.  From 
this,  an  overall  contingency  plan  can  be  developed 
that  provides  the  means  of  monitoring  the  ongoing 
effort  to  see  if  any  of  the  problems  are  occurring, 
and  initiate  a  pre-designed  plan  of  action  to  head 
them  off  if  they  do.  One  of  the  values  of  the 
technique  is  that  the  chart  can  be  posted  to  serve  as 
a  highly  visible  reminder  of  what  can  go  wrong 
during  an  improvement  effort. 

10.3.2.11  PERT/Gantt  Charts.  PERT  (Program 
Evaluation  and  Review  Technique)  and  Gantt  charts 
are  components  of  project  management  systems 
used  to  develop,  track,  and  display  project 
scheduling  data  by  task.  Each  phase  of  a  process 
improvement  project  should  be  scheduled  using  one 


or  both  of  these  techniques.  Automated  project 
management  software  systems  make  it  easy  to 
incorporate  these  techniques  in  any  project-oriented 
activity.  The  primary  requirement  to  use  them  is  to 
have  a  complete  work  breakdown  structure  (WBS) 
that  can  be  used  as  the  basis  for  schedule 
development.  The  tasks  that  make  up  the  25-step 
methodology  described  in  this  guide  should  be 
sufficient  detail  for  a  WBS. 

The  Project  Managers  Handbook  noted  in 
appendix  B  is  a  complete  guide  to  project 
management  principles  and  practices.  While  it  was 
developed  to  support  construction  projects  in  the 
U.S.  Army  Corps  of  Engineers,  it  can  still  be  easily 
adapted  to  process  improvement  projects. 

10.3.3  Operational  Techniques.  The  techniques 
described  below  are  called  operational  techniques 
because  they  should  be  used  on  an  ongoing  basis  to 
support  process  management  (see  section  2)  as  well 
as  process  improvement.  Often  process 
improvement  projects  and  actions  are  warranted  on 
the  basis  of  the  day-to-day  results  of  using  these 
operational  techniques.  When  process  problems 
occur  on  a  continuing  basis,  or  exceptional 
problems  reoccur  more  frequently  than  expected,  it 
can  be  an  indication  that  process  redesign  efforts  are 
required. 

10.3.3.1  Checksheets.  A  checksheet  is  a  simple 
method  of  collecting  recurring  process-related  data 
at  its  primary  source.  It  provides  an  easy,  structured 
means  of  recording  data  related  to  an  activity  that 
has  many  uses,  including  supporting  process 
management  and  improvement  efforts.  There  is  no 
standard  form  for  a  checksheet.  Each  checksheet  is 
specifically  designed  for  its  intended  purpose. 

There  are  guidelines  for  developing  them: 

■  The  checksheet  should  be  easy  to  use  as 
a  natural  add-on  to  a  routine  task  or 
ongoing  assignment. 

■  Each  entry  in  the  checksheet  should  take 
only  a  second  or  two  to  make. 

■  It  should  be  easy  to  organize,  tabulate, 
and  summarize  the  entries  on  the 
checksheet. 
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■  It  should  be  easy  to  spot  potential  or 
actual  problems  by  glancing  at  the 
checksheet. 

■  When  location  is  important  such  as  the 
number  of  defects  reported  for  a  product, 
the  checksheet  should  be  constructed  as  a 
model  or  a  map  of  the  product  to  give 
visual  evidence  of  where  most  problems 
are  occurring. 


Checksheets  can  be  used  to  find  patterns  in 
recurring  events.  Such  patterns  could  be  related  to 
time-of-day,  a  specific  machine,  an  individual 
operator,  a  particular  type  of  customer,  a  physical 
location,  etc.  Checksheets  provide  factual  data  that 
can  be  used  in  place  of  subjective  data  to  guide 
process  management  and  process  improvement 
efforts.  Checksheets  can  provide  data  that  can  be 
used  with  other  techniques  such  as  Pareto  charts  and 
cause  and  effect  diagrams. 


■  The  checksheet  should  be  coded  for  the  The  following  is  an  example  of  a  checksheet 

day  of  the  week,  time  of  day,  collection  used  to  log  types  of  customer  complaints. 
point,  person  doing  the  recording,  and 
any  other  factor  that  could  be  useful  in 
drawing  conclusions  from  the  checksheet 
data. 


I 

I 

I 


Customer  CoriHslaJnt  Week  Endhr®;  3/11/94 


Rude  sales  person 

xxxxxxxxxxxxxxxxxx 

18 

Selling  price  not  marked 

xxxxx 

5 

Evening  hours  too  short 

xxxxxxxxx 

9 

Waited  too  long  for  service 

xxxxxxxxxxxxxxxxxxxx 

20 

Poor  selection  for  "big  &  tall" 

XXX 

3 

Dressing  room  cramped 

xxxx 

4 

Too  expensive 

xxxxxx 

6 

Poor  location 

X 

1 

Poor  display 

xxxxxxx 

7 

Not  enough  styles 

xxxxxxxx 

8 

Poorly  lit 

XXX 

3 

Confusing  return  policy 

xxxx 

4 

Store  Clerk:  P.  Smith 

TOTAL 

88 

Figure  10-4.  Checklist 


40  Using  Quality  Improvement  Tools  to  Build  Customer  Satisfaction,  J.  Stephen  Sarazen,  American  Management 
Association  Extension  Institute,  1992. 
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10.3.3.2  Control  Sheets  (Run  Chart).  A  control 
sheet  or  run  chart  is  a  line  graph  plotted  over  time 
that  records  events  occurring  in  a  process.  Unlike 
the  checksheet  described  above,  the  control  sheet  is 
used  to  determine  the  amount  of  variation  in  a 
standard  process  over  time.  Unlike  a  histogram,  the 
control  sheet  shows  the  precise  time  that  an  out-of- 
control  event  occurred,  or  the  tendencies  of  the 
process  over  a  period  of  time. 

Control  sheets  are  closely  associated  with 
Statistical  Process  Control,  (SPC)  and  find  their 
primary  use  in  manufacturing  or  process  control 
applications.  Lately  SPC  techniques  have  been 
tried  with  success  on  service-based  processes.  The 
primary  requirement  is  having  an  acceptable  and 
reliable  way  to  collect  data.  Once  the  data  is 
collected,  it  is  subjected  to  statistical  evaluation  that 
provides  a  scientific  basis  for  establishing  the 
amount  and  nature  of  process  variation.  The 
variation  is  expressed  in  terms  of  standard  deviation 
(ie  6-sigma  quality),  number  of  out-of-range  events, 
and  patterns  of  process  performance.  These  data 
can  be  used  to  determine  when  a  process  is  in  need 
of  redesign  or  improvement. 

Successful  use  of  this  techniques  requires  a 
basic  understanding  of  statistical  methods  and 
design  of  experiments.  It  is  not  generally 
recommended  for  use  by  functional  people  who  do 
not  have  the  requisite  training. 

10.3.3.3  Cause  and  Effect  Analysis.  Cause  and 
Effect  (C&E)  diagrams  (also  called  fishbone 
diagrams  because  of  their  shape,  or  Ishikawa 
diagrams  because  of  their  creator)  are  useful  for 
many  purposes  in  process  management  and 
improvement.  C&E  diagrams  are  used  to  identify 
the  factors  that  contribute  to  a  problem,  a  solution, 
or  a  situation.  It  is  most  often  used  to  find  the  root 
cause(s)  of  a  given  problem,  or  the  basic  element(s) 
that  need  to  be  put  in  place  to  effect  a  solution  to  a 
problem. 

The  graphic  nature  of  a  C&E  diagram  makes  it 
effective  to  develop  although  it  takes  skill  and 
perseverance  to  develop  one  well.  A  C&E  diagram 
can  also  function  as  a  presentation  aid  when 
redrawn  in  a  simplified  manner. 


To  use  a  C&E  diagram,  the  problem  to  be 
solved  (the  effect)  is  written  at  the  right  end  of  a 
horizontal  line.  Diagonal  lines  are  drawn  on  either 
side  of  the  horizontal  line  with  each  line 
representing  a  major  facet  related  to  the  problem. 
Often  standard  headings  are  used  for  these  diagonal 
lines  consisting  of  people,  machines,  measurements, 
material,  information,  and  finances.  The 
improvement  team  then  brainstorms  for  all  the 
potential  causes  of  the  problem  in  each  category. 

As  a  cause  is  identified,  the  question  is  asked,  what 
caused  that  and  so  on  until  several  levels  of 
underlying  causes  are  uncovered.  With  this 
information,  the  process  improvement  team  can 
proceed  to  use  other  techniques  to  develop  solutions 
for  the  causes  of  the  main  problem. 

A  C&E  diagram  can  get  quite  messy  and  it 
must  sometimes  be  redrawn  or  broken  down  into 
smaller  units  (each  unit  headed  by  an  effect).  While 
not  as  effective  visually,  a  C&E  diagram  can  also  be 
developed  in  indented  outline  form.  It  is  also 
helpful  to  convert  a  completed  fishbone  diagram 
into  an  outline  form  before  proceeding  with  other 
techniques. 

10.3.4  Techniques  Matrix.  The  following  matrix 
can  be  used  as  a  guide  for  selecting  techniques  by 
process  improvement  phase.  This  matrix  is  only  a 
guide  and  should  not  be  interpreted  as  restricting  the 
use  of  techniques  to  any  particular  phases.  The 
following  symbols  are  used  in  the  matrix: 


■ 

PL- 

Planning  Phase 

■ 

RE- 

Process  Reengineering  Phase 

■ 

CM- 

Organizational  Change 

Management  Phase 

■ 

TI- 

Technical  Change 

Management  Phase 

■ 

EE- 

Enterprise  Engineering  Phase 

■ 

PE- 

Project  Execution  Phase. 

10.4  Automated  Tools 

Many  of  the  techniques  described  in  this 
section  are  supported  with  automated  tools.  For 
each  of  these  tools,  there  are  one  or  more 
commercial  or  government  off-the-shelf  products 
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TECHNIQUE  /  PHASE  MAPPING 

P.  -' 

R 

C 

L 

E 

M 

Survey/Interviews 


Site  Visits/Focus  Groups 


Questionnaires/Assessments 


Flowcharting 


Process  Deployment  Map/Matrix 


Creative  Thinking/Brainstorming 


Checksheets 


Nominal  Group  Technique 


Multi-voting 


Groupware  Tool 


Pareto  Diagrams 


Cause  and  Effect  Diagrams 


Affinity  Diagrams 


Relationship  Diagrams 


Tree  Diagrams 


Hoshin  Planning 


Process  Decision  Program  Charts 


Force  Field  Analysis 


Matrix  Diagrams 


Quality  Function  Deployment 


Figure  10*5.  Techniques  Matrix 
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available.  The  CIM  Center  for  Functional  Process 
Improvement  Expertise  maintains  an  up-to-date  list 
of  software  tools,  and  has  many  of  these  tools 
available  for  demonstration  or  for  use  on  a  loan 
basis.  Please  call  the  Center  at  this  number  for 
more  information:  1-703-892-4260. 

10.4.1  Groupware  Tools.  Lotus  Notes  and 
Vantana  V  are  two  widely  used  products  for 
supporting  groupware  requirements. 

10.4.5  Benchmarking  Tools.  The  American 
Society  for  Quality  Control  has  a  benchmark 
product  available.  They  can  be  reached  at  this 
number:  1-800-248-1946. 

10.4.6  Quality  Function  Deployment  Tools. 
Several  commercial  companies  are  now  introducing 
software  to  support  the  higher  matrices  of  QFD. 

10.4.2  Modeling  Tools.  Tools  such  as  Leverage 
and  Design  IDEF  are  readily  available  to  support 
modeling  workshops.  These  products  are 
productive  when  used  in  IDEF  workshops.  There 
are  also  several  commercial  programs  available  to 
support  process  mapping  and  flowchart  activities. 

10.4.3  Simulation  Tools.  Software  programs  to 
support  simulation  including  cycle  time  and 
resource  usage  are  becoming  available.  Some  of 


these  tools  are  designed  to  work  in  conjuction  with 
IDEF  models.  Others  require  model  development 
before  they  can  be  effectively  used. 

10.4.8  Economic  Analysis  Tools.  Several  products 
are  available  from  government  sources  for  use  in 
economic  analysis.  The  Support  Center  can  make 
these  available  on  a  loaner  basis. 

10.4.4  Project  Management  Tools.  There  are  a 
wide  variety  of  project  management  software  tools 
on  the  market.  They  range  from  easily  to  use  to 
extremely  robust.  Some  of  the  most  widely  used 
include  OpenPlan,  Harvard  Project  Manager,  and 
Primavera. 

10.4.7  Control  Sheet  Tools.  There  are  many 
statistical  tools  now  available.  Most  include 
software  that  supports  several  of  the  quality 
techniques  described  in  this  sections  such  as  cause 
and  effect,  barrier  analysis,  and  histograms. 
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SECTION  11.  BRE,  TQM  AND  INFORMATION  ENGINEERING 


This  section  discusses  some  general  concepts 
and  strategies  associated  with  process  improvement, 
and  the  relationship  of  process  reengineering  to 
other  methodologies.  Process  reengineering  shares 
many  of  the  same  objectives  and  goals  as  Total 
Quality  Management  (TQM),  especially  with 
respect  to  organizational  structure  and  cultural 
modernization.  Process  improvement  projects  will 
be  more  successful  and  implemented  faster  if  they 
mesh  well  with  the  organization’s  information 
engineering  strategy.  Finally,  project  improvement 
projects  must  be  conducted  according  to  accepted 
principles  of  project  management  if  risks  are  to  be 
minimized  and  improvement  costs  contained. 

11.1  Process  Improvement  Concepts 

This  section  reviews  some  of  the  principles  of 
process  improvement  and  defines  basic 
terminology.  It  also  elaborates  on  Section  2.2.5 — 
Functional  Integration,  and  Section  2.2.5 — 
Migration  and  Transition  Issues. 

11.1.1  Process.  A  process  is  defined  as  an 
organized  grouping  of  activities  that  takes  inputs 
(data  and  materials)  from  an  internal  or  external 
supplier,  adds  value  to  them  in  accordance  with  the 
purpose  of  the  process,  and  provides  the  output  to 
an  internal  or 


external  customer.  Processes  consume  resources  as 
they  transform  inputs  into  outputs.  Processes  are 
also  constrained  by  various  controls  imposed  on 
them. 

(Juite  simply,  if  the  value  of  the  outputs  of  an 
activity  exceed  the  total  cost  of  the  inputs  plus  the 
cost  of  the  resources  consumed,  the  activity  is 
considered  to  be  value  added.  If  not,  the  activity  is 
non-value  added.  The  purpose  of  process 
improvement  is  to  optimize  value  added  activities 
by  improving  quality  and  reducing  cycle  time,  while 
at  the  same  time  eliminating  or  minimizing  non¬ 
value  added  activities  and  costs. 


Enterpnses,  mcludmg  DoD  can  be  organized 


in  essentially  four  ways: 

■  Function 

■  Product  line 

■  Geography 

■  Process 


Accounting,  personnel, 
engineering 
Chrysler,  Dodge 
Central  Region,  Arizona 
Order  fulfillment, 
operational  intelligence. 


The  first  three  organization  types  are  basically 
hierarchical  (vertical  structures)  while  the  fourth. 
Process,  is  horizontal.  By  horizontal,  it  is  meant 
that  the  process  crosses  one  or  more  functional 
boundaries  within  the  enterprise. 


In  DoD,  sustaining  base  operations  are 
essentially  organized  by  function  while 
military  operations  are  organized  by  geography. 

Full  implementation  of  a  process  improvement  will 
require  a  move  to  a  more  horizontal  (process) 
management  structure,  because  vertically  organized 
enterprises  inherently  contain  huge  amounts  of  non¬ 
value  added  costs  and  activities.  We  give  the  name 
bureaucracy  to  this  phenomenon. 

Processes  can  be  viewed  in  their  entirety  in 
what  are  called  end-to-end  processes,  or  as  any 
level  of  subprocess.  Except  in  moderately  sized 
enterprises,  processes  must  usually  be  broken  down 
into  a  reasonable  size  before  process  improvement 
projects  can  be  conducted  with  a  reasonable 
expectation  of  success. 

11.1.2  Process  Modeling.  Modeling  functional 
processes  and  the  associated  data  and  information 
needs  is  a  fundamental  concept  in  the  process 
improvement  methodology.  Models  are  used  in  two 
ways;  first  to  define,  understand  and  communicate 
the  way  functional  processes  currently  work  (the 
AS-IS  condition);  and  then,  following  improvement 
analysis,  the  way  these  same  processes  could  or 
should  work  (the  TO-BE  conation).  The 
guidebook  Corporate  Information  Management: 
Process  Improvement  Methodology  for  DoD 
Functional  Managers  fully  introduces  the  concepts 
and  facilities  of  modeling. 
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11.12.1  Activity  model.  Activity  models  show  the 
interrelationships  among  the  activities  that  make  up 
a  functional  process  or  the  part  of  the  functional 
process  under  review.  These  interrelationships  are 
expressed  in  terms  of  ICOMs  where: 

■  I  means  input  (data  and  materials) 

■  C  means  control  (standards,  regulations, 
requirements,  budgets,  etc.) 

■  O  means  output  (products  and  services) 

■  M  means  mechanism  (labor  hours, 
machine  hours,  etc.). 

The  activities  that  make  up  a  process  are 
analyzed  by  a  technique  called  decomposition 
(subdividing  an  activity  into  its  component 
activities)  until  the  required  level  of  detail  is 
obtained. 

11.1.2.2  Data  model.  Data  models  show  the 
interrelationship  among  the  data  entities  that 
support  functional  processes.  A  data  entity 
represents  a  person,  place,  thing,  concept,  idea,  or 
event.  For  instance.  Employee  would  be  an  entity  in 
any  process  that  involves  employees. 

Entities  are  composed  of  attributes  (data 
items)  that  contain  information  about  the  entity.  In 
most  cases,  one  or  more  attributes  are  assigned  the 
role  of  keys  or  identifiers  for  the  entity.  Keys 
provide  a  means  of  selecting  and  accessing  an 
occurrence  of  an  entity  from  a  file  or  database 
system. 

11.U.3  AS-IS  condition.  When  both  an  activity 
and  a  data  model  have  been  developed  and 
validated  that  describe  how  the  functional  process 
under  study  actually  works,  the  AS-IS  condition  for 
the  process  has  been  established.  This  is  also  called 
the  baseline  for  the  process.  With  the  baseline 
established,  the  process  improvement  efforts  have  a 
fixed  starting  point  as  well  as  a  reference  point  for 
measuring  the  degree  of  improvement  obtained. 

The  concept  of  a  baseline  is  vital.  Without  a 
baseline,  improvement  efforts  run  the  risk  of  going 
in  circles  or  sub-optimizing  the  process  during 
redesign. 


11.1.2.4  TO-BE  condition.  There  are  many 
techniques  used  in  improvement  analysis.  Once  a 
set  of  potential  improvements  has  been  identified 
(called  an  initiative),  the  AS/IS  models  are  adjusted 
to  show  how  the  process  will  work  once  the 
improvements  are  implemented.  The  redesigned 
models  are  called  the  TO-BE  condition  for  the 
process.  More  than  one  set  of  TO-BE  models  may 
be  developed  if  there  are  alternative  designs  that 
will  implement  the  planned  improvements. 

The  TO-BE  models  have  many  uses: 

■  They  function  as  a  strawman  for 
discussion  purposes 

■  They  provide  a  means  of  testing 
improvement  assumptions 

■  They  help  communicate  proposed  slates 
of  improvements 

■  Once  a  set  of  improvements  is 
implemented,  they  can  easily  be  adjusted 
to  become  the  new  AS-IS  condition  (new 
baseline)  for  the  improved  process. 

11.1.3  Functional  Process  Integration.  It  is 
usually  not  feasible  to  initiate  process  improvement 
projects  for  functional  processes  that  are  large, 
complex  and  that  cross  many  organizational 
boundaries.  It  is  generally  too  disruptive,  requires 
too  many  people  on  the  process  action  team,  costs 
too  much  to  complete,  and  carries  with  it  a  high  risk 
of  failure. 

Functional  process  improvement  can  proceed 
in  stages,  each  of  which  deals  with  a  subset  of  the 
overall  processes.  At  the  proper  time,  these  subsets 
are  combined  using  the  concept  of  functional 
process  integration.  Figure  11.1  illustrates  this 
concept  within  a  functional  area  with  five  functional 
activities,  each  of  which  deals  with  one  part  of  the 
process.  As  shown  in  the  figure,  two  integration 
projects  will  be  launched  to  combine  (integrate)  the 
results  of  separate  improvement  efforts.  Project  (X) 
will  be  an  integration  of  the  efforts  of  projects  (A), 
(B),and(C). 
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Figure  11*1.  Functional  Integration 


The  goals  of  integration  are  to: 

■  Manage  strategic  changes  in  processes 
from  a  DoD-wide  perspective  to  achieve 
optimum  solutions  for  defined  customer 
needs 

■  Share  common  processes,  data  and 
support  mechanisms,  and  information 
systems — ^thereby  reducing  unneeded 
redundancy  and  overhead. 

The  strategy  for  integration  is  based  on 
developing  a  full  understanding  of  functional 
processes  by  building  activity  and  data  models, 
which  are  then  analyzed  to  uncover  opportunities 
for  integration  in  four  principal  areas: 

■  Measures  that  are  conunon  to  functional 
processes 

■  Data  in  order  to  maximize  the  use  of 
shared  data 

■  Methods  utilizing  best  practices 
techniques  to  optimize  performance 

■  Technologies  to  enhance  systems 
interoperability. 


The  DoD  Enterprise  Model  is  the  basis  for  all 
integration  activities  and  provides  a  framework  for 
initiating  and  managing  integration  efforts. 

Integration  efforts  are  managed  using  proven 
reengineering  techniques: 

■  Standard  data,  which  is  mandatory  for 
integration  efforts 

■  Resolve  inconsistencies  between 
performance  measures  and  critical 
success  factors  in  each  functional  area 
and  activity 

■  Look  for  integration  opportunities 
through  the  elimination  of  redundant 
activities  and  conflicts  in  resource 
utilization 

■  Standardize/consolidate  like  activities  or 
justify  the  maintenance  of  duplicate 
activities 

■  Assist  in  migration/integration  of  related 
information  systems 
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■  Develop  Data  Management  Plans 
(DMPs)  and  Technical  Management 
Plans  (TMPs)  to  a  sufficient  level  to 
support  integration  efforts. 

The  Defense  Data  Repository  System 
(DDRS),  which  contains  many  of  the  metadata 
(definition  and  model  data)  about  data,  processes, 
and  information  systems,  is  a  primary  tool  for 
integration  efforts.  Once  integration  at  the 
functional  level  is  accomplished,  integration  at  the 
technical  level  can  proceed  with  higher  levels  of 
confidence  that  enterprise  and  organizational  goals 
and  objectives  will  be  met. 

11.1.4  Performance  Measures.  Process 
improvement  projects  are  designed  to  improve  the 
performance  of  functional  processes.  The  term 
improvement  suggests  measurement.  Functional 
managers  must  know  the  critical  measures  of 
performance  that  will  be  used  to  judge  the  success 
of  their  improvement  efforts.  Performance 
measures  are  discussed  in  more  detail  in  Section  2 
of  this  guide.  Measmements  are  important  because 
they: 

■  Focus  attention  on  the  factors  associated 
with  successful  mission  achievement 

■  Indicate  how  efficiently  assigned 
resources  are  being  used 

■  Assist  in  setting  measurable  business 
objectives  and  monitoring  progress  in 
achieving  them 

■  Provide  input  for  improvement  analysis 
including  root  cause  analysis,  trendline 
analysis,  and  many  other  analysis 
techniques 

■  Provide  data  needed  for  benchmarking 
programs 

■  Set  employee  performance  targets 

■  Establish  a  means  of  monitoring  ongoing 
progress. 


11.1.5  Information  Systems.  Under  the  CIM 
program,  responsibility  for  effective  use  of 
information  system  assets  becomes  the 
responsibility  of  the  functional  managers  who 
benefit  from  them.  In  other  words,  the  functional 
manager  is  considered  to  be  the  customer  of 
information  services  on  a  fee-for-service  basis  and 
is  charged  with  the  responsibility  of  spending 
wisely  to  obtain  needed  services. 

The  technical  organizations  are  charged  with 
the  responsibility  of  maintaining  the  technological 
infirastructure  that  serves  the  DoD  as  a  whole.  By 
analogy,  assume  that  the  technical  organizations 
keep  the  furnace  in  good  repair,  but  the  functional 
managers  call  for  the  heat  they  need  in  their  own 
areas,  and  then  pay  for  it. 

It  is  the  objective  of  DoD  to  achieve  an  open 
systems  environment  that  can  support  all  of  the 
mission  areas  of  the  Department  utilizing  off-the- 
shelf  products,  shared  data  systems,  client-server 
architectures,  single  user  interface  (graphical, 
tactile,  and  voice-sensitive),  single  point  of  entry  for 
all  data — all  with  appropriate  privacy,  security,  and 
reliability  controls  in  place. 

Currently,  most  DoD  functional  processes  are 
supported  in  their  information  systems  needs  by 
legacy  systems.  Legacy  systems  are  the  systems 
currently  installed  in  DoD  agencies  and 
components,  many  of  which  are  technically,  if  not 
functionally,  obsolete  and  costly  to  maintain. 

Migration  systems  are  existing  information 
systems  that  have  been  selected  as  a  standard 
system  to  support  existing  processes.  Whenever 
feasible,  two  or  more  legacy  systems  are 
consolidated  into  one  migration  system.  Some 
migration  systems  may  evolve  directly  into  an  open 
systems  environment. 

Target  systems  are  migration  systems  that 
have  been  upgraded  to  support  process 
improvement  actions  bas^  on  approved  functional 
economic  analysis  (FEA)  decision  packages.  Over 
time,  target  systems  will  be  converted  to  the  open 
systems  environment. 
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Figure  11.2  shows  the  relationships  of  these 
systems  categories  and  how  legacy  systems  will 
eventually  be  converted. 

11.2  Total  Quality  Management  (TQM) 
Concepts 

In  our  traditional  management  system, 
each  department,  intact  team,  and 
individual  keeps  its  head  down  and  does 
the  job  assigned.  Within  the  thick,  high 
walls  of  each  function’s  “stovepipe,” 
individual  contributors,  teams,  and 
management  staff  work  to  optimize  the 
efficiency  of  their  own  unit. 

Performance  appraisals,  merit  rating 
systems,  and  compensation  are  all 
designed  to  reinforce  this  narrow  view. 

In  this  system,  senior  and  middle 
managers  use  their  “command  and 
control”  hierarchy  to  plan,  direct,  staff, 
coordinate,  and  control  the  functional 


units.  Deep  inside  their  dark  stovepipes, 
with  little  or  no  contact  with  their 
internal  or  external  customers  or 
suppliers,  workers  and  their  supervisors 
look  up  the  stovepipe  to  management 
and  their  support  staff  for  direction  and 
feedback. 

We  now  know  this  system  is  obsolete.  It 
is  too  slow... and  improvements  are  often 
not  focused  on  customer  needs.  In 
simpler  times,  this  system  worked.  In 
today’s  much  more  complex  and  fast- 
moving  world,  this  approach  is  about  as 
useful  as  buggy  whips  and  Morse  code. 
Those  organizations  still  clinging  to  this 
vertical  structure  are  collapsing,  like 
planned  communist  economies,  under  the 
weight  and  cost  of  their  lumbering, 
unresponsive  bureaucracy. 
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Connecting  teams  to  their  internal  and 
external  suppliers  and  customers  and 
helping  them  to  cooperatively  manage 
processes  as  they  flow  across  functions 
will  flatten  hierarchies  as  well  as  smash 
stovepipes. 

—  Jim  Clemmer, 
Firing  on  all  Cylinders,page  83 


Government  and  industry  have  come  to 
understand  that  previously  acceptable 
quality  norms  of  goods  and  services  are 
no  longer  acceptable. 

Customer  satisfaction,  reliability, 
productivity,  costs  and  for  industry, 
market  share,  profitability,  and  even 
survival  are  directly  affected  by  the 
quality  of  an  organization’s  products, 
services  and  performance. 

Therefore,  it  becomes  essential  to 
develop  attitudes  and  systems — at  all 
levels  of  an  organization — ^that  promote 
and  implement  continuous  improvement 
of  procedures,  processes,  products  and 
services.  Those  attitudes  and  systems  are 
the  focus  of  Total  Quality  Management 
(TQM),  also  termed  Totd  Quality 
Leadership  (TQL).. 

The  objective  of  TQM  is  to  broaden  the 
focus  of  quality  to  embrace  the  concept 
of  continuous  process  improvement.  To 
change  the  concept  of  quality  from  the 
traditional  to  the  modem  as  listed  below; 


Traditional  Modem 

Defect  correction  Defect  prevention 

Quality  by  inspection  Quality  by  design 

Acceptable  levels  World  class  quality 

of  defects 

Emphasis  on  cost  Emphasis  on  quality, 

and  schedule  cost,  and  schedule 

— Total  Quality  Management  Guide, 
A  Two  Volume  Guide  for  Defense  Organizations, 

Final  Draft,  2/15/90 


Total  Quality  Management  is  about  transforming 
organizations  from  Ae  industrial  age  paradigm  to  an 
information  age  paradigm.  TQM  principles  are 
quite  compatible  with  process  reengineering 
principles.  The  objective  is  the  same — to  improve 
processes.  Differences  are  in  degree  of  change, 
speed  of  change,  and  technique.  This  section  will 
focus  on  some  of  the  improvement  areas  and 
concepts  particularly  emphasized  by  TQM 
practitioners. 

11.2.1  Domains.  The  design  factors  for  quality 
exist  at  three  levels:  the  core  product  or  service,  the 
support  available  to  the  customer,  and  the  service 
enhancements  that  represent  the  intangibles  that 
provide  customer  satisfaction.  Process  owners 
should  consider  the  quality  implications  at  all  three 
levels  as  part  of  an  improvement  program. 

The  organization  itself  controls  the  first  two 
domains  of  quality — the  core  product  and  the 
support  package  that  goes  with  it.  These  are  often 
referred  to  as  “Hi-Tech”  items.  But  the  individual 
employee  who  is  in  direct  contact  with  the  customer 
controls  the  third  domain,  enhanced  service.  This  is 
often  referred  to  as  “Hi-Touch.”  This  is  why 
quality  and  process  improvement  programs  must 
involve  everyone  in  the  organization  because 
virtually  everyone  has  a  customer,  the  recipient  of 
his  or  her  work  project.. 

11.2.1.1  Core  product  functionality.  This  domain 
is  concerned  with  the  actual  product  or  service 
delivered  to  customers.  There  are  essentially  three 
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elements  of  concern  with  respect  to  improvement 
programs: 

■  Meeting  minimum  customer 
requirements 

■  Product/service  reliability 

■  Ease  of  use. 

11.2.1.2  Product  support.  This  domain  covers  all 
of  the  support  services  available  with  the  basic 
product  or  service.  The  most  important  factors  with 
respect  to  quality  include: 

■  Accessibility 

■  Convenience 

■  Dependability 

■  Maintenance  and  service 

■  Repair  and  replacement 

■  Installation  and  training. 

11.2.1.3  Customer  Service.  This  domain  is  more 
difficult  to  characterize  because  it  primarily  deals 
with  the  specific  day-to-day  interactions  between 
customers  and  employees,  which  are  not  within  the 
direct  control  of  management.  Quality  in  this 
domain  is  a  function  of  values  and  beliefs  and  how 
well  they’re  practiced,  employee  empowerment  to 
act,  training  in  quality  and  service,  and  the  degree  to 
which  the  organization  is  service-driven  rather  than 
rule-driven. 


11.2.2  Variables.  There  are  four  primary  variables 
to  be  considered  in  quality  management  programs. 
Figure  11.3  shows  the  way  TQM  positions  quality- 
related  variables.  For  instance,  fitness  for  purpose 
is  a  product  characteristic  that  is  evident  outside  of 
the  organization,  while  conformance  to  standard  is 
more  of  an  internal  variable.  Organizational  values 
affect  employees  and  are  easy  to  discern  from 
outside  the  organization,  while  cultural  values  are 
more  of  an  internal  value. 

11.2.2.1  Fitness  for  purpose.  This  variable 
primarily  influences  the  product  or  service  and  the 
consequences  are  felt  outside  of  the  organizational 
unit.  Joseph  Juran  promotes  fitness  for  purpose  as  a 
major  element  in  the  concept  of  quality  and  teaches 
that  when  quality  is  designed  into  the  product,  the 
product  will  be  fit  for  use. 

Quality  questions  associated  with  this  variable 
include: 

■  How  will  the  product  be  used? 

■  Where  will  the  product  be  used? 

■  Who  will  be  the  users? 

■  Are  there  any  potential  dangers  to  health 
and  safety? 


,  ,  ,  '  .  '  .  '  5  '  '  '  '  .V,  '  S  ■<' 
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Fitness  for  Purpose 

Cultural  Values 

Conformance  to 
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Figure  11-3.  Quality  Variables 
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■  Are  there  any  potential  risks  to  society  or 
the  environment? 

■  What  is  the  urgency  for  delivery? 

■  What  other  sources  for  the  product  exist? 

■  Are  there  any  innovative  uses  for  the 
product? 

11.2.2.2  Conformance  to  standards.  This  variable 
primarily  influences  the  product  or  service  and  the 
conse(]uences  are  felt  within  the  organizational  unit. 
W.  Edwards  Deming  was  a  proponent  of  statistical 
quality  control  and  taught  that  constant  vigilance  is 
the  key  to  maintaining  high  quality  standards.  He 
promoted  the  Shewhart  cycle,  named  after  Walter 
Shewhart,  which  entails  continuous  process 
improvement  and  innovation. 

PLAN  Develop  product  specifications 

based  on  customer  needs.  Develop 
performance  measures  and  the 
means  to  check  them. 

DO  Design  the  processes  that  will 

produce  the  products  and  services. 
Work  the  processes  and  collect 
quality,  service,  and  management 
data. 

CHECK  Develop  variances  of  actual 

performance  to  plan  and  develop 
improvement  initiatives  to  correct 
deficiencies. 

ACT  Implement  the  process 

improvement  program  and 
incorporate  new  technologies  as 
appropriate. 

11.2.2.3  Cultural  Values.  This  variable  primarily 
influences  the  employee,  and  the  consequences  are 
felt  within  the  oiganizational  unit.  The  Total 
Quality  Management  culture  is  based  on  three 
factors: 

■  Management  commitment  and  leadership 

■  Training  and  skill  in  applying  the 
techniques  and  tools  of  process 
improvement 


■  Organization-wide  involvement  and 
employee  empowerment. 

Without  a  strong  quality  training  program  that 
considers  all  three  aspects,  most  quality  and  process 
improvement  programs  and  projects  will  fail,  or 
deliver  far  less  value  than  they  could  have. 

Our  present  culture  is  permeated  by  an 
atmosphere  of  distrust.  We  devise  intricate 
checks  and  balances  to  control  every  action 
with  a  bureaucracy  that  boggles  the  mind  and 
causes  excessive  administrative  costs. 

Meanwhile,  we  fail  to  train  our  managers  for 
leadership,  pay  little  attention  to  the  system 
that  allows  counterproductive  efforts  to  go 
unchallenged,  do  not  properly  educate,  train 
or  motivate  our  personnel  to  be  effective  and 
productive,  nor  do  we  allow  them  to 
contribute  to  the  full  extent  of  their 
abilities....Rather,  we  should  be  putting  the 
desired  achievements  on  the  spot  light, 
provide  leadership  and  incentives  for 
success,  and  measure  and  reward  in 
accordance  with  achievements. 

— Total  Quality  Management  Guide, 
A  Two  Volume  Guide  for  Defense  Organizations, 

Final  Draft,  2/15/90 

11.2.2.4  Organizational  Factors.  This  variable 
primarily  influences  the  employee,  and  the 
consequences  are  felt  outside  the  organizational 
unit.  Continuous  process  improvement  and  the 
quality/service  environment  can  only  flourish 
within  the  limits  established  by  the  organizational 
structure. 

Rigid  hierarchical  organizational  structures, 
layer  upon  layer  of  management  and  oversight,  rule- 
based  rather  Aan  performance-based  reward 
systems,  thick  procedures  books  and  a  form  for 
every  purpose — all  work  against  establishing  an 
organization  that  can  prosper  as  a  Total  Quality 
Management  enterprise. 
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The  effects  of  organization  are  felt  outside  the 
organization  and  have  major  impacts  on  the  third 
domain  of  quality  described  above.  If  a  customer 
hears  any  of  the  following  remarks  from  an 
employee  either  on  the  phone  or  in  person,  it  is  a 
sign  of  probable  organizational  constipation. 

■  I’m  sorry,  I  can’t  help  you. 

■  You’ll  have  to  come  back  tomorrow. 

■  I  have  to  take  my  break  now. 

■  We  don’t  do  that/we’re  not  allowed  to  do 
that. 

■  That’s  not  my  department/there’s  nothing 
I  can  do. 

■  Could  you  call  back  some  other  time. 

■  I  don’t  know  anything  about  that 
product/service/problem. 

■  He  doesn’t  work  here  any  more,  and  he 
had  your  file. 

■  You’ll  have  to  get  in  that  other  line. 

The  ideal  organization: 

■  Is  managed  primarily  by  process  rather 
than  function 

■  Uses  self-managed  teams  that  are 
empowered  to  make  decisions 

■  Is  intensely  focused  on  customer  service 

■  Is  performance,  rather  than  rule-based 

■  Rewards  unit  performance  and  individual 
skill  development 

■  Has  minimi  but  sufficient 
administrative  controls. 

11.23  Improvement  Objectives  Independent  of 
Methodology.  Both  process  reengineering  and 
TQM  have  the  same  goals  with  respect  to  the 
business  process  itself.  The  characteristics  of  a 
well-managed  process  are  listed  below.  If  the 
process  in  question  is  deficient  in  one  or  more  of 
these  areas,  process  improvement  is  called  for 
whether  the  methods  used  are  reengineering  or 
TQM. 

This  list  of  process  attributes  can  be  the 
beginning  of  a  meaningful  process  vision  statement. 

■  The  process  is  assigned  to  a  process 
owner  who  is  accountable  for  results. 


■  The  process  is  well-bounded  with  respect 
to  the  enterprise,  and  external  customers 
and  suppliers  have  been  identified. 

■  The  internal  (subprocess)  boundaries 
have  workable  interfaces  between  the 
process  and  internal  customers  and 
suppliers. 

■  All  controls  (policies,  procedures, 
standards,  mles  and  regulations)  are 
applicable,  appropriate,  and  well- 
documented. 

■  Performance  measures,  key  indicators, 
and  critical  success  factors  are  in  place 
and  used  as  part  of  a  continuous 
improvement  program. 

■  All  products  and  services  have  been 
validated  against  tme  customer  needs 
and  requirements  and  are  best-in-class. 

■  All  suppliers  are  involved  in  the 
continuous  improvement  process. 

■  Resources  are  used  primarily  to  support 
value  added  activities,  the  unit  costs  of 
all  major  outputs  are  known,  and  the 
“tooth/tail”  ratio  is  optimum  for  each 
class  of  output. 

■  There  is  minimum  waste,  rework,  rejects, 
returns,  service  call-backs,  customer 
complaints,  and  other  negative  measures 
associated  with  the  processes’  inputs  and 
outputs. 

■  The  process,  products  and  services,  and 
performance  targets  have  been  developed 
or  validated  using  benchmarking  and 
best  practices  techniques. 

113.4  The  TQM/BRE  Relationship.  TQM  (or 
Total  (Quality  Leadership— TQL)  and  process 
reengineering  (BRE)  are  closely  related.  The 
differences  are  more  academic  or  political  than  real. 
Much  organizational  grief  can  be  avoided  by 
downplaying  the  names  given  to  process 
improvement  and  focusing  on  the  application  of 
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BRE  is  biased  toward  dealing  with  these 
issues: 


whatever  methods,  techniques,  and  tools  will  get  the 
job  done. 

In  time,  there  may  be  no  practical  distinction 
between  TQM  and  BRE.  Both  concepts  deal  with 
essentially  the  same  elements  and  strive  for 
common  objectives.  If  there  are  distinctions,  they 
are  ones  of  emphasis  rather  than  exclusion.  The 
reader  may  feel  free  to  move  any  of  the  following 
issues  from  one  category  to  the  other. 

TQM  is  biased  toward  dealing  with  these 
issues: 

■  Cultural  issues 

■  Management  and  organizational 
structuring 

■  Reward  and  recognition  systems 

■  Mission  and  function  reEnement 

■  Strategic  and  business  planning 

■  Customer  relations 

■  Product  feature  specification 

■  Controls,  constraints  and  standards 

■  Product  quality  more  than  services 
quality 

■  Benchmarking 

■  Process  design 

■  High-Touch 

■  Continuous  improvement. 


■  Process  issues 

■  Process  analysis  and  redesign 

■  Supplier  relations 

■  Input  requirements  (data  and  materials) 

■  Resource  management  and  utilization 

■  Cost  driver  management 

■  Best  practices  analysis 

■  Information  systems  support  issues 

■  Services  quality  over  product  quality 

■  Cost  issues 

■  Response  and  throughput  time  issues 

■  High-Tech 

■  Quantum  (orders  of  magnitude)  levels  of 
improvement. 

Figure  11.4  shows  how  TQM  and  BRE  arrive 
at  the  mutual  objective  of  satisfying  customers  and 
producing  superlative  products  and  services.  To 
read  the  chart  from  the  perspective  of  a  TQM 
practitioner,  start  at  the  top  and  move  toward  the 
center  and  to  the  right.  To  read  it  from  the 
perspective  of  a  BRE  practitioner,  start  at  the 
bottom  and  move  toward  the  center  and  to  the  right. 
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Figure  11-4.  TQM/BRE  Chart 
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TQM  planning  and  implementation  issues 
center  around  management  and  organizational 
issues;  BRE  planning  and  implementation  issues 
deal  with  processes. 

11.3  Information  Engineering  Concepts 

Information  engineering  is  concerned  with 
devising  automated  systems  that  support  functional 
processes  consistent  with  the  overall  technical 
infrastructure  established  by  the  OSD.  The 
technical  elements  function  as  a  supplier  of 
information  services  to  the  process  or  functional 
manager  who  is  the  customer.  Value-chain  analysis 
theory  hold  that  suppliers  (technical  elements)  are 
an  integral  part  of  process  improvement  planning. 

Information  engineering  uses  a  standard 
methodology  and  various  techniques  and  tools  to 
create  applications  and  database  structures  based  on 
functional  activity  and  data  models.  The  Defense 
Data  Repository  System  (DDRS)  is  designed  to 
facilitate  the  relationship  between  the  functional  and 
the  technical  elements. 

Actual  application  systems  development 
proceeds  in  accordance  with  the  Life  Cycle 
Management  of  Information  Systems  (LCMIS) 


program  using  a  variety  of  computer-aided  software 
engineering  tools  (CASE). 

The  techniques  and  tools  incorporated  into  the 
three  methodologies  of  Total  Quality  Management, 
Process  Reengineering,  and  Information 
Engineering  can  be  used  together  to  construct  the 
modem  enterprise.  Figure  11-5  suggests  the 
relationships  among  these  three  methodologies. 

The  emphasis  in  TQM  is  to  ensure  that  the 
enterprise  knows  what  it  is  trying  to  achieve  and 
why.  Strategic  and  business  planning  techniques 
are  used  to  understand  the  environment  in  which  the 
enterprise  functions,  the  customers  it  will  serve,  and 
the  products  and  services  it  will  build  to  serve  those 
customers.  As  part  of  this  process,  the  enterprise 
adapts  a  quality  culture  and  restructures  its 
organization  into  an  information  age  paradigm. 

The  functional  architecture,  described  in  DoD 
8020. 1-M,  is  the  linkage  between  the  planning 
aspects  of  TQM  and  functional  process 
improvement.  The  functional  architecture  contains 
data  about  mission,  scope,  rales,  methods, 
management  processes,  goals,  objectives, 
performance  measures,  performance  targets  and  the 
functional  management  strategy. 
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Figure  11-5.  TQM-BRE-IE  Relationship  Model 
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From  the  functional  architecture,  BRE 
techniques  are  used  to  develop  AS-IS  data  and 
activity  models,  cost  models,  and  cycle  time  data. 
The  AS-IS  models  form  the  basis  for  improvement 
analysis,  which  leads  to  a  series  of  improvement 
initiatives. 

Techniques  are  used  to  develop  alternative 
approaches  to  implementing  improvement 
initiatives  and  performing  economic  analysis  on 
those  alternatives. 

Proposed  improvement  packages  are  used  to 
transform  the  AS-IS  models  into  TO-BE  activity 
and  data  models,  which  reside  in  the  DDRS.  (AS- 
IS  models  are  also  stored  in  the  DDRS.) 

Meanwhile,  the  functional  manager  prepares  the 
FEA,  which  contains  the  proposed  improvement 
packages  along  with  all  business,  functional, 
economic,  and  technical  justification  data. 

Once  the  FEA  is  approved,  the  information 
systems  components  of  the  improvement  package 
can  be  developed  by  the  information  engineering 
staff  using  the  facilities  of  the  DDRS  and 
appropriate  CASE  tools.  The  role  of  the  software 
engineers  (using  LCMIS  methods)  is  to  produce  the 
supporting  application  systems  and  restructure  the 
corporate  databases  to  accommodate  the  change 
initiative. 

The  PPBS  crosses  all  methodologies  and  acts 
as  a  consolidation  and  control  vehicle,  as  well  as  a 
means  of  conununicating  the  proposed  impacts  and 
potential  effects  of  all  actions,  changes,  and  new 
developments  to  higher  authority. 

11.4  Life  Cycle  Project  Management  Concepts 

The  Frameworic  methodology  for  process 
improvement  is  designed  for  compatibility  with 
project  management  principles  in  general,  and  life 
cycle  project  management  (LCMIS)  requirements  in 
particular. 

11.4.1  Concepts  of  Project  and  Project 
Management.  All  process  improvement  programs 
and  actions  should  be  organized  and  managed  as  a 
project.  A  project  has  the  following  characteristics: 


■  It  is  well-organized  and  includes 
appropriate  team  members. 

■  It  is  well-planned  using  Work 
Breakdown  Structure  concepts. 

■  It  is  well-executed  using  Critical  Path 
Methods  for  schedule  control. 

■  It  is  well-tracked  using  proven  exception 
handling  procedures. 

■  Its  management  is  well-coordinated  with 
functional  management. 

■  Project  records  and  documentation  are 
appropriately  maintained. 

The  critical  success  factors  for  project 
management  include  the  following: 

■  Attention  to  organization  and  team 
building 

■  Project  conceptualization  and  planning 

■  Rigorous  schedule  and  milestone 
performance  management 

■  Rigorous  budget  management 

■  Enlightened  human  resource 
management 

■  Effective  coordination  and 
communications  management 

■  Organized  records  management 

■  Use  of  automated  project  management 
support  tools 

■  Conformance  to  policy  and  directives. 

Other  important  elements  necessary  to 
successful  project  management  include: 

■  Full  support  from  senior  leaders 

■  Selection  of  a  well-trained  project 
manager 

■  Appropriate  facilities  apart  from  the 
normal  work  stations 

■  Appropriate  computer  hardware, 
software,  office  machines, 
communications,  and  training  and 
presentation  equipment 

■  Administrative  support  for 
documentation  and  records  management 
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■  Facilitation  and/or  consultative  support 

■  Sufficient  time  and  funds  to  do  the  job 
right  the  first  time. 

11.4.2  Life  Cycle  Managementc.  Life  Cycle 
Management  of  Information  Systems  (LCMIS)  is  a 
program  designed  to  optimize  the  development  and 
deployment  of  information  systems  on  a  DoD-wide 
basis.  The  LCMIS  program  helps  ensure  that 
information  systems  dollars  are  spent  wisely  by 
ensuring  that  existing  systems  are  utilized  to  their 
capacity  and  requests  for  new  systems  will  not 
result  in  duplication  of  effort  and  unnecessary 
redundancy. 

The  LCMIS  program  is  used  in  conjunction 
with  process  improvement  whenever  the  FEA 
proposes  a  new  information  system  or  significant 
modifications  to  existing  information  systems. 

The  LCMIS  process  is  structured  as  follows. 

■  Manage  and  Oversee  the  LCMIS  Process 

—  Provide  Corporate  Information 
Management 

—  Manage  Planning,  Progranuning, 
Budgeting  System 

—  Manage  Life  Cycle  Management 
Information  Systems 
—  Manage  Acquisition 
—  Conduct  Information  Systems 
Integration 

—  Conduct  MAISRC 

■  Perform  LCMIS  Project  Management 

—  Plan  Project 
—  Manage  Resources 
—  Manage  System  Engineering 
—  Develop  Acquisition 
Documentation 

—  Conduct  Cost/Benefit  Analysis 
—  Prepare  MAISRC 


■  Perform  Systems  Engineering 

—  Perform  Concept  Development 
—  Perform  Design 
—  Perform  Development 
—  Perform  System  Integration 
—  Perform  Deployment 
—  Perform  Operational  Transition. 

11.4.3  Project  Planning.  The  most  important 
considerations  for  project  planning  is  that  the 
project  plan  must  be  in  writing  and  that  it  be 
reviewed  and  approved  by  all  interested  parties 
prior  to  project  execution.  The  key  elements  in  a 
well-developed  project  include  the  following: 

■  Statement  of  Purpose 

■  Scope  of  Work 

■  Work  Breakdown  Structure 

■  Organizational  Breakdown  Structure 

■  Responsibility  Assignment  Matrix 

■  Schedules  and  Milestones 

■  Budgets  and  Cost  Estimates 

■  Quality  Management  Plan 

■  Management  Control  Plan. 

Most  process  improvement  programs  have  a 
planned  duration  (life  cycle)  of  six  months,  but  may 
range  from  about  two  to  twelve  months.  The 
project  plan  should  be  as  simple  as  possible  based 
on  the  expected  complexity  of  the  project  itself.  As 
a  rule  of  Aumb,  project  management  activities 
(organization,  planning,  and  execution)  should 
consume  no  more  than  15%  of  the  total  estimated 
project  time. 

11.4.4  Project  Execution.  Once  the  project  plan  is 
approved,  project  execution  consists  primarily  of 
tracking  performance  against  plan  and  swiftly 
dealing  with  deviations  in  scope,  work  item 
definition,  assignments,  schedule  conflicts  and 
performance,  cost  performance,  and  unplanned 
contingencies  (issues  and  problems). 

A  process  improvement  project  may  be 
organized  into  plaiming  and  execution  phases  that 
correspond  to  the  phases  in  the  improvement 
methodology  (Framework).  That  is.  Phase  2, 
Process  Reengineering,  may  have  a  complete  and 
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separate  project  plan;  while  Phase  3,  Enterprise 
Engineering,  may  have  its  own  plan.  This  is 
generally  preferable  to  trying  to  plan  the  entire  six 
phases  of  process  improvement  because  there  are 
too  many  unknowns,  and  budget  and  schedule 
estimates  will  be  higher  suspect. 
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SECTION  12.  SUPPORT  FOR  PROCESS  IMPROVEMENT  PROJECTS 


Process  improvement  is  now  an  important 
mission  within  the  Department  of  Defense. 

Because  functional  managers  are  expected  to  take 
the  lead  in  initiating  and  conducting  process 
improvement  projects,  the  Office  of  the  Secretary 
of  Defense  has  established  an  extensive  system  of 
support  services  to  aid  functional  managers  in 
carrying  out  their  responsibilities. 

Support  services  include  an  extensive 
documentation  library,  training  programs  available 
in  a  wide  variety  of  media  and  delivery  systems; 
workshops  that  furnish  just-in-time  training  and  on- 
the-job  facilitation  on  improvement  projects;  and 
sources  for  additional  training,  consultation, 
facilitation,  and  access  to  expertise  from  a  number 
of  agencies  and  components  involved  in  process 
improvement. 

This  guidebook  refers  to  some  of  these 
support  services  in  Appendix  D.  If  you  don’t  find 
what  you  are  looking  for  there,  the  next  step  is  to 
call  the  CIM  Process  Improvement  Hotline  at  1- 
800-TELL-CIM.  If  the  hotline  staff  cannot  answer 
your  questions,  they  will  direct  you  to  someone 
who  can. 

12.1  Documentation 

The  documentation  resources  available  to 
support  process  improvement  teams  include  official 
DoD  publications,  guidebooks  and  other  informal 
materials  developed  by  or  for  the  Department,  and 
commercial  books  and  articles  relating  to  process 
reengineering  and  total  quality  management.  In 
addition,  many  DoD  Agencies  and  Components 
have  developed  useful  materials  out  of  their 
experience.  Many  of  these  materials  are 
inventoried  by  the  Defense  Technical  Information 
Center  (DTIC),  and  can  be  ordered  directly  from 
them.  For  other  sources,  call  the  hotline. 

Many  of  the  most  important  and  useful 
documents  are  available  on  a  CD-ROM 
disc  which  is  updated  two  or  three  times  a  year. 

The  CD-ROM  contains  what  otherwise  would  be 
about  two  feet  of  paper  documents.  In  addition,  the 
CD-ROM  includes  an  index  software  program  to 


help  you  quickly  locate  the  information  you  need. 
Plans  call  for  a  hypertext  version  of  the  CD-ROM 
in  the  near  future. 

12.1.1  Framework  for  Managing  Process 
Improvement.  The  Framework  concept  includes 
an  entire  library  of  documents  oriented  around  the 
six-phase,  25-step  methodology  described  in  this 
document.  As  of  March  1, 1994,  the  following 
documents  are  available: 

■  F/MPI  Methodology  Briefing 

■  F/MPI  Planning  Tutorial 

■  F/MPI  Performance  Cell  IXitorial 

■  F/MPI  Organizational  Change 
Management  Tutorial. 

Approximately  25  supporting  documents  are 
planned  for  the  series,  and  most  will  be  available  by 
September  30, 1994.  Section  3.3  in  this  guide  gives 
a  general  description  of  the  planned  Framework 
library. 

12.1.2  Process  Improvement  Guidebooks. 
Guidebooks  are  designed  to  support  major  steps  in 
the  methodology  and  offer  extensive  instructions  on 
how  to  prepare  key  deliverables  complete  with 
examples  and  other  supporting  information.  As  of 
March  1, 1994,  the  following  guidebooks  are 
available: 

■  Process  Improvement  Methodology  for 
the  DoD  Functional  Manager 

■  Functional  Economic  Analysis 

■  Functional  Process  Simulation 

■  Preparing  for  and  Initiating  Functional 
Process  Improvement  Programs 

■  Functional  Process  Improvement  Quality 
Plan. 

The  reader  should  be  aware  that  the  methods 
and  techniques  of  process  improvement  are  in  a 
high  state  of  flux;  and  there  are  differences  in 
terminology,  concepts,  methods  and  techniques  in 
many  of  the  publications  and  documents  related  to 
the  process  improvement  program.  In  time,  these 
differences  will  be  resolved. 
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12.1.3  Other  Support  Documentation.  The 

Department  of  Defense  is  approaching  process 
improvement  and  quality  management  using  the 
principles  of  benchmarking  and  best  practices. 
Because  of  this,  there  is  a  concerted  effort  to  use 
industry  terminology  and  adopt  the  best  methods 
and  techniques  wherever  they  may  be  found.  This 
means  that  virtually  all  of  the  professional  literature 
on  process  improvement  and  quality  management  is 
applicable  to  DoD’s  program.  Functional  managers 
involved  in  process  improvement  may  want  to 
acquire  some  of  the  most  important  references  listed 
in  Appendix  B. 

As  experience  is  gained  with  process 
improvement,  there  are  a  number  of  case  studies 
and  lessons  learned  becoming  available.  For 
instance,  a  report  is  available  summarizing  the 
benchmark  that  was  conducted  in  August  1993  by 
the  Assistant  Director  for  Business  Process 
Improvement.  This  study  covered  12  private  and 
commercial  enterprises  engaged  in  programs  of 
process  improvement.  A  case  study  of  the  Merced 
County,  C^ifomia,  experience  in  reengineering  a 
welfare  system  is  now  available.  The  case  study 
emphasizes  the  organizational  change  management 
aspects  of  reengineering  and  will  be  profitable 
reading  for  any  government  agency  contemplating  a 
major  reengineering  effort. 

12.2  Training 

Training  programs  are  rapidly  being  developed 
to  support  process  improvement  projects.  Many  of 
these  programs  are  available  now  or  are  being 
developed  by  DISA/CIM.  The  Information 
Resource  Management  College  (IRMC)  has  a 
number  of  executive-level  courses  available  on 
process  improvement.  The  Army  Management  and 
Engineering  College  (AMEC)  has  a  full  curriculum 
of  courses  covering  all  aspects  of  process 
improvement  and  total  quality  management. 

Several  contractors  have  been  tasked  to  develop 
additional  courses.  The  International  School  of 
Information  Management  (ISIM)  has  two  distance 
learning  courses  available  on  process  improvement. 


12.2.1  Skills  for  Process  Improvement  Action 
Teams.  The  primary  skills  needed  to  successfully 
participate  in  a  process  improvement  program  fall 
into  three  categories: 

■  Methodology  expertise  as  contained  in 
this  guidebook 

■  Skill  in  selecting  and  applying  the 
techniques  described  in  Section  10 

■  Teamwork  skills  including  the  personal 
skills  noted  in  Appendix  E. 

The  success  criteria  for  a  process 
improvement  team  member  include  the  following, 
which  together  could  be  described  as  teamwork 
skills.  However,  it  is  doubtful  whether  these 
attributes  can  be  taught  in  a  training  course. 

■  Fimctional  expertise  in  one  or  mote 
business  process  areas 

■  Comfortable  with  technology,  computers 
and  information  systems 

■  Empowered  to  function  in  a  process 
improvement  team 

■  Team  player  who  strives  for  synergy  and 
is  supportive  of  others 

■  Articulate  and  concise 

■  Open-minded  and  will  to  listen  to  others 

■  Creative  and  visionary 

■  Trustworthy  and  discreet 

■  Seeks  opportunities  to  improve  processes 

■  Persuasive,  able  to  constmct  a  logical 
argument  for  a  plan  of  action 

■  Deals  well  with  conflict  and  ambiguity 

■  Politically  astute  and  can  discern  which 
battles  can  be  won  or  lost 

■  Conscientious  and  dependable 

■  Optimistic,  enthusiastic  and  wants  to 
help  the  team  succeed 

■  Respected  by  business  peers  and  senior 
management 

■  Proactive  and  not  afraid  to  take  a  risk 

■  A  good  listener  with  good  interviewing 
skills 

■  Has  leadership  potential. 
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Considering  the  skills  and  attributes  thought 
necessary  for  process  improvement  team  members, 
it  is  not  difficult  to  understand  why  most 
organizations  who  have  achieved  success  report  that 
it  takes  five  to  ten  years  to  establish  a  culture 
supportive  of  process  improvement  efforts. 

12.2.2  TVaining  Philosophy.  We  look  to  the 
authorities  in  the  field  of  process  reengineering  and 
continuous  process  improvement  for  enlightenment 
on  the  theory  and  practice  of  training.  From  these 
authorities  and  out  of  our  own  experience  in 
applying  the  methods  and  techniques  will  evolve  a 
distinctly  DoD  training  philosophy  in  support  of 
process  improvement. 

Organizations  are  undergoing  rapid  change  in 
the  way  they  operate  and  the  way  people 
think,  talk  and  act.  This  change  process  must 
be  supported  by  an  aggressive  training 
program  that  reinforces  these  changes  and 
provides  growth  opportunities  for  your 
employees. 

Process  improvement  team  (PIT)  members 
must  be  trained  to  work  as  a  team, 
understand  the  process,  collect  and  analyze 
data  and  improve  the  process.  As  a 
prerequisite  to  becoming  a  PIT  member,  each 
individual  should  have  been  trained  in  and 
should  have  used  basic  team  and  problem¬ 
solving  tools  such  as: 

■  Team  process 

■  Brainstorming 

■  Check  sheets 

■  Graphs 

■  Histograms 

■  Pareto  diagrams 

■  Scatter  diagrams 

■  Nominal  group  techniques 

■  Delphi  narrowing  technique 

■  Force-field  analysis 

■  Cause-and-effect  diagrams 

■  Mind  maps 

■  Statistical  process  control 

In  the  long  mn,  a  team  lacking  training  and 
skills  will  not  completely  comprehend  the 
situation  it  is  trying  to  improve  and  will  not 
implement  the  best  combination  of  solutions. 

— H.  James  Harrington, 
Business  Process  Improvement, 


Education  in  quality  methodologies  is  crucial 
and  necessary  if  a  company  is  to  succeed  and 
achieve  its  quality  vision,  to  increase  its 
productivity,  and  to  ensure  increasing 
customer  satisfaction.  Listed  here  are  some 
basic  quality  methodologies  that  should  be 
part  of  an  employee  education  effort. 

■  Introduction  to  Total  Quality  Control 

■  The  Plan,  Do,  Check,  Act  (PDCA) 

improvement  cycle 

■  Fourteen  quality  control  techniques 

■  Taguchi  methods 

■  Quality  circle  member  training 

■  Quality  function  deployment  (QFD) 

■  Sampling  techniques 

■  Hoshin  planning 

■  How  to  achieve  customer  satisfaction 

— Sarv  Singh  Soin,  Total  Control  Essentials, 

Every  study  of  high-service/quality  providers 
shows  that  training  plays  a  huge  role  in  the 
improvement  process.  Training  consists  of 
understanding  what  is  to  be  done  and  why 
(education  and  awareness)  and  then 
developing  the  ability  to  make  the  targeted 
changes  happen  (skills).. ..Often  the  greatest 
education  and  awareness  challenge  on  the 
road  to  higher  service/quality  is  getting 
people  to  let  go  of  their  old  paradigms...  Your 
people  need  help  grasping  the  basic  service/ 
quality  concepts  and  understanding  your 
organization’s  vision,  values,  improvement 
strategies  and  plans.  They  also  need  a 
chance  to  discuss  their  role,  next  steps, 
concerns  and  the  like.  Your  introduction  to 
service/quality  should  contain  the  following 
elements. 


■  Why  improve  service/quality? 

■  What  is  service/quality? 

■  What  are  our  old  assumptions  and  new 
paradigms? 

■  What’s  our  reason  for  being,  vision  and 
values? 

■  What’s  the  territory  (scope)  to  be 
covered? 

■  How  will  this  be  deployed? 

■  What  are  the  next  steps? 
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U.S.  Navy  Captain  Jerald  Gartman  led  a 
service/quality  revolution  at  Cherry  Point 
Aviation  Depot  in  North  Carolina  that  saved 
millions  of  dollars.  Extensive  training  was 
central  to  the  effort.  Captain  Gartman  says 
the  payback  on  training  proved  to  be  $14.00 
to  $1.00.  He  concludes,  “Training  is  very, 
very  expensive  and  ignorance  costs  more 
than  you  can  imagine.’* 

— Jim  Clemmer,  Firing  on  all  Cylinders, 

One  of  the  more  successful  options  has  been 
to  use  a  broad-based  task  force  for  the 
purpose  of  designing  the  (quality) 
curriculum.  Under  this  concept  the  Quality 
Council  creates  a  task  force  (project  team) 
whose  mission  is  to  develop  a  plan  for 
training  in  planning  for  quality... 

The  task  force  mission  is  to: 

■  Identify  the  company’s  needs  for 
training  in  planning  for  quality 

■  Propose  a  curriculum  of  courses  that 
can  meet  those  needs 

■  Identify  which  categories  of  personnel 
should  take  which  courses 

■  Identify  the  sources  of  needed  training 
materials,  whether  to  be  self-developed 
or  acquired  from  suppliers 

■  Identify  the  needs  for  leaders:  trainers, 
facilitators 

■  Propose  a  timetable 

■  Estimate  the  budget. 

— ^Joseph  M.  Juran,  Quality  by  Design, 

One  of  the  essential  ingredients  of  a  broad- 
scope  quality  program  is  an  extensive 
amount  of  training.  Experience  in  training 
has  identified  the  reasons  why  some  quality 
programs  fail: 

■  Failure  to  provide  training  at  the  time  it 
will  be  used  (just-in-time) 

■  Lack  of  participation  by  line  managers 
in  designing  training 

■  Reliance  on  the  lecture  method  of 
training 

■  Poor  communication  during  training 
(poor  instructors). 

— Joseph  M.  Juran, 
Quality  Planning  and  Analysis. 


Often  the  key  element  that  is  missing  in 
efforts  to  improve  work-flow  processes  is  the 
training  that  will  enable  empowered  teams  of 
employees  to  do  their  jobs.  Classroom  and 
on-the-job  training  ensures  that  employees 
are  adequately  equipped  with  the  sldlls  to 
perform  their  work,  and  includes  training  in 
quality  management  concepts  and  skills  such 
as  teamwork,  problem-solving  and  methods 
for  collecting  and  analyzing  data  using  basic 
statistical  tools. 


To  support  this  massive  quality  effort,  Xerox 
creat^  an  extensive  training  program.  All 
Xerox  employees  have  received  at  least  the 
basic  28-hour  Leadership  Through  Quality 
training;  many  have  been  trained  in  advanced 
quality  techniques.  Over  the  last  four  years, 

Xerox  has  invested  four  million  man-hours 
and  $125  million  in  Leadership  Through 
Quality  training. 

— ^V.  Daniel  Hunt,  Managing  for  Quality. 

One  of  the  first  things  necessary  for  a  robust 
benchmarking  program  is  a  good  internal 
training  program  that  teaches  your  teams 
how  to  conduct  a  benchmarking  study. 

Education  changes  thinking;  training  changes 
behavior,  both  are  needed  in  benchmarking. 

— Gregory  H.  Watson, 

The  Benchmarking  Workbook. 

Employee  involvement,  teamwork,  and 
integration — ^these  conditions  of  excellent 
companies  do  not  occur  because  of  executive 
mandate.  Employees  must  be  enabled  to 
create  such  conditions  of  excellence. 

Education  and  training  of  all  employees  is 
the  most  powerful  enabler  of  people  in  the 
Baldrige  view....Investment  in  education  is 
the  capital  expenditure  in  the  human  side  of 
quality.  As  such,  it  is  of  primary  interest  and 
importance  to  Baldrige  examiners. 

— Christopher  W.L.  Hart  and  Christopher  E. 

Bogan,  The  Baldrige. 

12.2.3  TVaining  Delivery  Modes.  There  are  many 
training  methods  available  for  process  improvement 
training  programs.  Five  key  methods  are  discussed 
below. 
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12.2.3.1  TVaditional  iiistructor*led  training. 

While  this  is  the  most  common  method  of  training 
in  the  United  States,  it  is  by  far  one  of  the  most 
inefficient.  It  is  inefficient  in  three  ways: 

■  Cost 

■  Skill  development 

■  Retention. 

Cost:  When  students  must  travel  to  the 
training  site,  typical  training  costs  can  run  as  high  as 
$500.00  per  day  per  student.  This  figure  takes  into 
account  travel  costs,  student  salary  costs,  instmctor 
costs,  and  materials  costs.  It  does  not  take  into 
account  facilities  or  special  equipment. 

Skill  development:  Most  instructor-led 
training  is  lecture-based.  This  is  the  least  effective 
means  of  developing  skills  in  the  student 
population.  The  more  woricshop-oriented  (hands- 
on)  the  training  experience,  the  more  likely  that 
skills  will  be  developed. 

Retention:  Studies  have  shown  that  student 
retention  of  material  presented  in  instructor-led 
training  rapidly  declines  to  about  20%  of  the 
material  covered.  Many  factors  influence  this 
number  but,  in  general,  it  is  the  acceptable  figure. 

Instructor-led  training  in  the  Management 
Framework  for  Process  Improvement  (MF/PI) 
should  be  workshop  oriented  and  should  use  case 
studies,  role  plays,  field  trips  and  other  interactive 
means  of  conveying  the  subject  material. 

12.2.3.2  Self-paced  training.  This  method  of 
training  is  suitable  for  instruction  in  basic  skills 
such  as  process  improvement  techniques.  Good 
self-paced  materials  are  expensive  to  produce  and 
maintain  and  therefore  can  only  be  used  in  a  cost- 
effective  manner  when  the  training  population  for  a 
given  course  exceeds  about  500  students. 

12.2.3.3  Just-in-time  training.  This  method  of 
training  is  rapidly  gaining  favor  because  it  focuses 
learning  activities  on  material  that  will  be  used  on 
the  job  soon  after  the  training  event  is  complete. 
Just-in-time  techniques  woric  best  with  local 
seminar/workshop  training  and  with  self-paced 
training.  It  is  not  generally  practical  to  use  just-in¬ 


time  concepts  with  instractor-led  training  when 
travel  time  is  involved. 

12.2.3.4  Distance  learning.  Distance  learning  is  a 
method  of  computer-managed  training  where 
students  are  enrolled  in  an  electronic  classroom. 

The  students  and  instructors  are  dispersed  and 
communicate  using  a  personal  computer  and  a 
modem.  This  method  of  training  is  gaining 
popularity  because  it  combines  several  desirable 
training  concepts: 

■  It  is  instructor-led  in  the  sense  that  an 
instructor  gives  assignments,  reviews 
student  work  and  is  available  to  answer 
questions.  The  instructor  is,  of  course, 
only  available  via  electronic  mail  and 
possibly  by  telephone. 

■  The  student  works  at  his  or  her  own  pace 
within  a  given  timeframe  for  completing 
an  assignment.  Thus,  distance  learning 
does  not  unduly  interfere  with  the 
students  other  activities.  School  is  in 
session  24  hours  a  day,  seven  days  a 
week. 

■  There  is  no  travel  time  or  cost  involved. 

■  Courses  can  be  designed  and  scheduled 
to  be  taken  just  in  time  to  improve 
student  retention  factors. 

■  Because  there  is  no  lecture  component, 
distance  learning  courses  tend  to  be  skill- 
based.  Conceptual  knowledge  is  gained 
ftom  reading  assignments,  and  the 
student  evidences  comprehension  by 
completing  a  written  assignment  or 
project. 

12.2.3.5  Behavior  modification  training.  This 
method  of  skill-based  training  is  based  on  extensive 
research  on  adult  learning.  It  was  developed  in 
1969  by  Melvin  Sorcher,  a  General  Electric 
industrial  psychologist,  based  on  some  pioneering 
work  in  clinical  psychology.  The  method  has 
enjoyed  a  high  degree  of  success  wherever  it  has 
been  conscientiously  applied.  Behavior 
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modification  training  methods  are  based  on  an 
eight-step  methodology: 

■  Provide  evidence  that  the  skill  to  be 
learned  is  important 

■  Explain  the  specific  behaviors  (actions) 
that  are  involved  in  the  skill 

■  Demonstrate  the  skill  in  a  variety  of 
work  settings 

■  Provide  the  conceptual  framework  for 
the  skill  (knowledge  required) 

■  Allow  the  student  to  practice  the  skill 
(real  or  simulated) 

■  Provide  constructive  feedback  on  student 
performance  (reinforce/coach) 

■  Assist  students  in  identifying  occasions 
for  using  the  skill  on  the  job  site 

■  Follow  up  within  six  months  on  progress 
in  applying  the  skill  to  the  job. 

12.2.4  Institutions.  Institutions  providing  training 
services  include  the  following: 

■  Information  Resource  Management 
CoUege  (IRMC) 

■  Army  Management  and  Engineering 
College  (AMEC) 

■  International  School  of  Information 
Management  (ISIM) 

12.2.5  Process  Improvement  Curricula.  New 

training  opportunities  are  constantly  being 
developed  to  support  process  improvement.  For  the 
latest  training  curricula  from  the  institutions  and 
agencies  providing  process  improvement  training, 
and  a  list  of  available  courses,  please  call  the  CIM 
Hot  Line:  1-800-TELL-CIM. 

12.3  Workshops 

At  presently,  there  are  five  standard 
workshops  that  support  process  improvement 
projects.  Each  workshop  is  designed  to  accomplish 


specific  tasks  and  produce  specific  deliverables. 

The  length  of  any  given  workshop  will  vary  from 
two  to  eight  weeks,  depending  on  its  focus  and 
requirements.  There  is  generally  a  requirement  to 
perform  offline  activities  between  workshops  such 
as  data  gathering,  interviewing,  research,  and 
benchmarking. 

12.3.1  Scoping  Workshop  -  two  weeks.  Training 
is  provided  in  overall  methodology  with  detailed 
instruction  in  the  specific  use  of  IDEF  techniques. 
Facilitators  assist  Ae  project  team  in  refining  the 
project’s  context,  objectives,  and  opportunity  areas. 
Mission,  objectives,  and  goals  are  assessed.  Also 
provided  are  high-level  activity  and  data  modeling, 
which  may  include  producing  “strawman”  models. 
A  specific  project  plan  is  also  developed.  This 
initial  workshop  includes  daily  project  facilitation, 
leadership,  focus,  and  support. 

12.3.2  Baseline  Workshop  -  six  weeks.  Guided  by 
the  facilitator,  the  project  team  develops  and 
decomposes  the  AS-IS  model  using  IDEF 
techniques.  The  project  team  is  guided  in 
determining  what  analysis  is  to  be  done,  identifying 
the  data  for  analysis,  and  capturing  improvement 
opportunities.  The  project  team  also  receives 
assistance  from  the  facilitator  in  validating  the  AS- 
IS  model  and  in  collecting  data  for  cost,  time,  and 
quality  analysis.  Preliminary  analysis  is  made  on 
Ae  collected  data.. 

12  J.3  Improvement  Analysis  Workshop  -  six 
weeks.  Improvement  analysis  continues  aided  by 
activity  based  costing,  process  flow,  and  quality 
analysis  exercises.  This  effort  is  designed  to 
determine  the  potential  areas  of  improvement  and 
aid  in  identifying  and  consolidating  common 
functions,  eliminating  non- value  added  activities 
and  costs,  and  streamlining  the  process.  Using 
these  data,  the  project  creates  the  process  vision  and 
TO-BE  models.  The  team  prepares  the  preliminary 
FEA  and  aids  in  the  preparation  of  the  preliminary 
implementation  or  functional  strategic  plan.  The 
facilitator  provides  assistance  in  the  technical  and 
analytical  aspects  of  activity  and  data  modeling,  as 
well  as  in  activity  based  costing  technique,  process 
flow,  simulation,  and  quality  analysis. 
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12.3.4  Final  Validation  Workshop  -  six  weeks. 
The  team  validates  the  TO-BE  models  and 
supporting  models  and  narratives,  and  develops  the 
implementation  plan.  The  team  completes  the 
implementation  plan  and  the  final  FEA  and  prepares 
a  final  report.  Implementation  begins,  which  may 
include  fiinctional  changes,  system  changes,  pilots, 
prototypes,  and  training. 

12.3.5  Integration  Workshop  -  two  weeks.  The 
work  done  thus  far  is  evaluated  with  respect  to  the 
DoD  Enterprise  Model  and  opportunities  for  cross¬ 
functional  integration  are  explored. 


12.4  Support  Services.  Support  services  provided  by  DISA/ 
Improvement  include  the  following: 

■  Methodology  support 

■  Project  startup  and  management 

■  BPI  training  for  the  CADRE  100 

■  BPI  Program  Hotline  Support 

■  Support  of  IDEE  modeling 

■  FIPS  Standards  development 

■  Model  conversion  and  integration  assistance 

■  IDEF  repository  management 

■  FEA  consultation 

■  Loaner  tools 

■  Guidebooks 

■  BPI  consulting 

■  Best  business  practices. 
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ANNEX  A.  GLOSSARY 

Activity  -  A  name  process,  function,  or  task  that 
occurs  over  time  and  has  recognizable  results. 
Activities  combine  to  form  business  processes. 

Activity  Accounting  -  The  collection  of  financial 
and  operation  performance  data  about  significant 
activities  of  an  enterprise. 

Activity-Based  Costing  (ABC)  -  An  accounting 
technique  that  allows  an  enterprise  to  determine  the 
actual  costs  associated  with  each  product  and 
service  produced  by  that  enterprise  without  regard 
to  the  organizational  structure  of  the  enterprise. 

Activity-Based  Management  (ABM)  -  A  system  of 
management  that  seeks  to  optimize  the  value-added 
activities  performed  by  the  enterprise  while  at  the 
same  time  minimizing  or  eliminating  the  non-value 
added  activities,  resulting  in  overall  improvements 
in  the  effectiveness  and  the  efficiency  of  the 
enterprise  in  serving  its  customers. 

Activity  measure  -  A  performance  value  assigned 
to  an  activity’s  primary  output. 

Activity  model  -  A  graphic  representation  of  a 
business  process  that  exhibits  the  activities  and  their 
interdependencies  that  make  up  the  business  process 
to  any  desired  level  of  detail.  An  activity  model 
reveals  the  interactions  between  activities  in  terms 
of  inputs  and  outputs  while  showing  the  controls 
plac^  on  each  activity  and  the  types  of  resources 
assigned  to  each  activity. 

Activity  model  (AS-IS)  -  An  activity  model  that 
portrays  how  a  business  process  is  currently 
structured.  It  is  used  to  establish  a  baseline  for 
subsequent  business  process  improvement  actions  or 
programs. 

Activity  model  (TO-BE)  -  An  activity  model  that 
results  from  a  business  process  redesigned  action  or 
program.  The  TO-BE  model  shows  how  the 
business  process  will  function  after  the 
improvement  action  is  implemented. 


Activity,  non-value  added  -  Any  activity  that 
provides  a  negative  return  on  the  investment  or 
allocation  of  resources  to  that  activity.  Within 
broad  limits,  the  enterprise  benefits  by  allocating 
less  resource  to  non-value  added  activities. 

Activity,  value  added  -  Any  activity  that 
contributes  directly  to  the  performance  of  a  mission, 
and  could  not  be  eliminated  without  impairing  the 
mission. 

AIS  -  Automated  Information  System 

AMEC  -  Army  Management  Engineering  College 

AS-IS  Model  -  A  model  that  represents  the  current 
state  of  the  organization  modeled,  without  any 
specific  improvements  included,  (contrast  with  TO- 
BE  Model). 

Baseline  -  The  current  condition  that  exists  in  a 
situation  or  representation  (model)  of  a  situation. 
Usually  used  to  differentiate  between  a  current  and 
a  future  representation. 

Benchmarking  -  A  method  of  measuring  processes 
against  those  of  recognized  leaders  to  establish 
priorities  and  targets  leading  to  process 
improvement.  It  is  undertaken  by  identifying 
strategies,  customers,  processes  and  costs  to 
benchmaiic  and  their  key  characteristics; 
determining  who  to  benchmark;  collecting  and 
analyzing  data  from  direct  contact,  survey, 
interviews,  technical  journals,  and  advertisements; 
determining  the  “best  of  class”  from  each 
benchmark  item  identified;  and  evaluating  the 
process  in  terms  of  improvement  goals. 

Best  practice  -  A  way  or  method  of  accomplishing 
a  business  function  or  process  that  is  considered  to 
be  superior  to  all  other  known  methods. 

BUI  of  Activity  -  BOA.  A  structured  listing  of  the 
sequence  of  activities  performed  to  produce  a  unit 
of  a  product  or  service.  Similar  in  concept  to  a  bill 
of  materials  (BOM),  which  is  a  structured  list  of  the 
components  of  a  product. 
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Business  case  -  A  structured  proposal  for  business 
process  improvement  that  functions  as  a  decision 
package  for  enterprise  leadership.  A  business  case 
includes  an  analysis  of  business  process  needs  or 
problems,  proposed  solution,  assumptions  and 
constraints,  alternatives,  life  cycle  costs,  benefits/ 
cost  analysis,  and  investment  risk  analysis.  Within 
DoD,  a  business  case  is  called  a  Functional 
Economic  Analysis  (FEA). 

Business  process  -  A  collection  of  activities  that 
work  together  to  produce  a  defined  set  of  products 
and  services.  All  business  processes  in  an 
enterprise  exist  to  fulfill  the  mission  of  the 
enterprise.  Business  processes  must  be  related  in 
some  way  to  mission  objectives. 

Business  Process  Improvement  (BPI)  -  The 

betterment  of  an  organization’s  business  practices 
through  the  analysis  of  activities  to  reduce  or 
eliminate  non-value  added  activities  or  costs,  while 
at  the  same  time  maintaining  or  improving  quality, 
productivity,  timeliness,  or  other  strategic  or 
business  purposes  as  evidenced  by  measures  of 
performance.  Also  called  functional  process 
improvement. 

CT  -  Command,  Control,  Communications,  and 
Intelligence 

Cadre  100  -  A  team  of  approximately  100 
functional  managers  and  professionals  who  are 
taking  a  leading  role  in  functional  process 
improvement  activities  within  DoD. 

CIM  -  Corporate  Information  Management 
Initiative  (ODDI) 

CIM  -  Center  for  Information  Management  (DISA/ 
CM) 

CIM  Integration  Architecture  -  A  master  plan  for 
building  the  Defense  Integrated  Information  (DEI) 
technology  platform.  The  DoD  CM  Architecture 
supports  a  seven-level  approach  to  defining 
information  systems  implementation  activities. 

This  ensures  that  all  such  efforts  proceed  from 
mission  requirements,  organizational  objectives, 
and  business  process  needs  to  workable  systems 


that  are  compatible  with  the  current  geographic  and 
technological  infrastructure.  Together,  the  seven 
levels  provide  a  consistent  platform  for  all  systems 
operations. 

Continuous  process  improvement  -  A  policy  that 
encourages,  mandates,  and/or  empowers  employees 
to  find  ways  to  improve  process  and  product 
performance  measures  on  an  on  going  basis. 

Cost  center  -  A  function  in  a  business  where  the 
cost  of  producing  a  product  or  service  is  tracked  and 
personnel  are  held  accountable  for  performance. 

Customer  -  The  recipient  of  an  output  product  or 
service.  May  be  internal  or  external  to  the 
organization. 

Database  -  A  collection  of  related  data,  organized 
to  serve  one  or  more  independent  applications, 
stored  with  security,  privacy,  and  integrity  controls. 

Data  model  (Business  Rule  Model)  -  A  graphical 
representation  of  an  organization’s  information  and 
data  assets  expressed  in  terms  of  entities  and 
relationships.  Relationships  are  also  called  business 
rules  because  they  enable  or  constrain  business 
actions.  Data  models,  like  activity  models,  have 
AS-IS  and  TO-BE  representations. 

Data  repository  -  A  specialized  database 
containing  information  about  data  and  data 
relationships.  Used  to  provide  a  common  resource 
of  standard  data  elements  and  models. 

DBOF  -  Defense  Business  Operations  Funds 

DDI  -  Director  of  Defense  Information 

Defense  Management  Review  Decision  (DMRD)  - 
The  reductions  from  budgets  mandated  by  the  DoD 
comptroller. 

Dn  -  Defense  Information  Infrastructure 

DISA  -  Defense  Information  Systems  Agency 

Discounted  cash  flow  -  A  method  of  performing  an 
economic  analysis  that  takes  the  time  value  of 
money  into  account.  Used  to  remove  interest  rates 


A-2 


Glossary 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


and  inflation  factors  from  a  calculation  so  that  the 
results  of  analysis  are  comparable. 

DMP  -  Data  Management  Plan 

Driver  -  The  root  cause  of  a  condition  or 
measurement  that  is  felt  downstream  in  a  process  as 
in  cost  driver  and  quality  driver. 

DTIC  -  Defense  Technical  Information  Center 

EA  -  Economic  Analysis 

Economic  analysis  -  A  formal  method  of 
comparing  two  or  more  alternative  ways  of 
accomplishing  a  set  objective,  given  a  set  of 
assumptions  and  constraints  and  the  costs  and 
benefits  of  each  alternative,  such  that  the  analysis 
will  indicate  the  optimum  choice.. 

Enterprise  -  When  used  generically,  an  enterprise 
is  defined  as  the  aggregate  of  all  functional 
elements  participating  in  a  business  process 
improvement  action  regardless  of  the  organizational 
structure  housing  those  functional  elements. 

Enterprise  level  -  The  Enterprise  Level  of  the  CIM 
Integration  Architecture  provides  the  geographic, 
technological,  and  managerial  platform  upon  which 
all  information  systems  development  activity  is 
based;  it  is  the  foundation  that  must  support  all  that 
is  built  above  it  in  the  higher  levels.  In  general,  it  is 
synonymous  with  the  entire  Department  of  Defense. 

Enterprise  model  -  DoD  Enterprise  Model.  A 
high-level  model  of  the  Department’s  mission, 
function,  process,  and  information  architecture  used 
as  a  standard  reference  for  constructing  data  and 
activity  models  and  information  systems. 

Fee  for  service  -  A  policy  that  determines  the 
charge  for  a  given  product  or  service  based  on  the 
calculated  costs  of  producing  the  product  or  service 
with  or  without  a  margin  (profit  figure). 

Fixed  cost  -  A  cost  that  does  not  vary  with  the 
amount  or  degree  of  production.  The  costs  that 
remain  if  an  activity  or  process  stops. 


Function  -  A  specific  set  of  skills  and  resources  that 
can  be  used  to  perform  one  or  more  activities  that 
make  up  a  process.  Usually,  several  functions  are 
associated  with  a  single  process. 

Functional  activity  -  A  subdivision  of  a  functional 
area. 

Functional  area  -  One  of  eight  process  groupings 
with  DoD.  The  eight  functional  areas  are  Finance, 
Health,  Human  Resources,  Reserve  Components, 
Materiel  Resources,  Procurement,  Information 
Management,  and  Command  and  Control. 

Functional  Economic  Analysis  (FEA)  -  A 
technique  for  analyzing  and  evaluating  alternative 
information  system  investments  and  management 
practices.  Within  DoD,  FEA  is  a  business  case. 
Also,  a  document  that  contains  a  fully  justified 
proposed  improvement  project  with  all  supporting 
data,  i.e.  Business  Case  or  Decision  Package. 

Functional  management  -  A  philosophy  of 
management  that  organizes  an  enterprise  by  type  of 
work  performed.  See  also  process  management. 

Functional  process  -  A  subdivision  of  a  functional 
activity 

Functional  Process  Improvement  (FPI)  -  A 
structured  approach  by  all  or  part  of  an  enterprise  to 
improve  the  value  of  its  products  and  services  while 
reducing  resource  requirements.  Also  referred  to  as 
business  process  improvement  (BPI),  business 
process  redesign,  and  business  reengineering. 

Functional  Process  Improvement  Program 
(FPIP)  -  A  focused  initiative  within  DoD  to 
encourage  consistent  application  of  process 
improvement  principles  and  techniques  across  its 
services  and  agencies.  Also  referred  to  as  business 
process  improvement  program  (BPIP). 

IDA  -  Institute  for  Defense  Analysis 

IDEF  -  Integrated  Definition  Language 


Glossary 


A-3 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


IDEF  Modeling  techniques  -  A  combination  of 
graphic  and  narrative  symbols  and  mles  designed  to 
capture  the  processes  and  structure  of  information 
in  an  organization.  IDEFO  is  an  activity,  or 
behavior,  modeling  technique;  IDEFIX  is  a  rule,  or 
data,  modeling  technique. 

IM  -  Information  Management 

Improvement  initiative  -  A  set  or  package  of 
planned  improvements  resulting  from  the  analysis 
of  baseline  processes,  inspection  of  strategic  and 
business  plans,  and  benchmarking  results  that,  if 
implemented,  will  result  in  process  improvement. 

Improvement  opportunities  -  Situations  that  can 
be  changed  to  produce  a  more  effective  or  more 
efficient  process  or  product.  Improvement 
opportunities  may  involve  processes,  business  rules, 
or  both.  Opportunities  are  often  packaged  together 
as  an  improvement  initiative. 

Information  technology  -  IT.  A  package  of 
equipment  and/or  systems  related  to  data  and/or 
communications  that  can  be  used  as  an  enabler  of 
process  reengineering. 

Integrated-Computer  Aided  Software 
Engineering  (I-CASE)  -  A  set  of  software  design 
and  development  tools  operating  with  an  integrated 
shared  repository  to  support  the  entire  systems 
development  life  cycle. 

Investment  justification  -  A  functional  economic 
analysis  indicating  that  it  is  better  to  do  a  certain 
action  than  not  do  it.  Investments  may  be  compared 
and  ranked  by  various  criteria,  including  return  on 
various  categories  of  capital,  risk-adjusted 
discounted  cash  flow,  affordability,  internal  rate  of 
return,  etc. 

IRMC  -  Information  Resources  Management 
College 

Just  in  time  -  A  policy  calling  for  the  delivery  of 
materials,  products  or  services  at  the  time  they  are 
needed  in  an  activity  or  process.  Used  to  reduce 
inventory,  wait  time,  and  spoilage. 


Life  Cycle  Management  -  LCM.  A  management 
process  that  governs  a  process  or  system  firom 
conception  to  final  disposition.  Also,  Life  Cycle 
Management  of  Information  Systems,  LCMIS. 

MAISRC  -  Major  Automated  Information  System 
Review  Council 

Migration  system  -  An  existing  information  system 
that  has  been  officially  designated  to  support 
standard  processes  and  is  intended  to  be  the  means 
of  arriving  at  a  target  system  or  architecture  (as  in 
open  systems  architecture). 

Model  -  A  representation  of  a  complex,  real-world 
phenomenon  such  that  it  can  answer  questions 
about  the  real-world  phenomenon  within  some 
acceptable  and  predictable  tolerance. 

Non-value  added  activity  -  An  activity  performed 
in  a  process  that  does  not  add  value  to  the  output 
product  or  service,  which  may  or  may  not  have  a 
valid  business  reason  for  being  performed. 

Similarly,  non-value  added  cost. 

ODDI  -  Office  of  the  Director  of  Defense 
Information 

Performance  measure  -  An  indicator  that  can  be 
used  to  evaluate  quality,  cost,  or  cycle  time 
characteristics  of  an  activity  or  process  usually 
against  a  target  or  standard  value. 

PPBS  -  Program,  Programming,  and  Budgeting 
System 

Present  value  -  The  current  value  of  a  future  series 
of  cash  flows  given  a  discount  factor  or  interest 
value.  Used  to  evaluate  the  alternative  investments. 

Process  -  A  collection  of  activities  that  together 
produce  a  usable  product  or  service  by  applying 
resources  from  one  or  more  functional  areas. 

Process  Action  Team  (PAT)  -  A  group  of  “hands- 
on”  people  assembled  as  part  of  a  Total  Quality 
Management/Total  (Quality  Leadership  (TQM/tQL) 
project  to  solve  a  specific  operational  problem. 
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Process  management  -  A  philosophy  of 
management  that  organizes  an  enterprise  by  the 
series  of  activities  that  combine  to  produce  related 
types  of  goods  and  services  for  internal  or  external 
customers.  See  functional  management. 

Process  model  -  See  Activity  Model. 

Quality  Function  Deployment  (QFD)  -  A 
requirements  identification  analysis,  flow  down, 
and  tracking  technique.  It  focuses  on  quality  and 
communication  to  translate  customer  needs  into 
product-  and  process-design  specifics.  Also  known 
as  the  “house  of  quality.” 

Redesign  -  Business  Process  Redesign  (BPR).  The 
transformation  of  a  business  process  to  achieve 
signiHcant  levels  of  improvement  in  one  or  more 
performance  measures  relating  to  fitness  for 
purpose,  quality,  cycle  time,  and  cost  by  using  the 
techniques  of  streamlining  and  removing  non- value 
added  activities  and  costs.  Redesign  projects 
typically  take  about  six  months  to  complete. 

Reengineering  -  Business  Process  Reengineering 
(BRE).  The  radical  transformation  of  a  business 
process  to  achieve  orders  of  magnitude 
improvement  in  one  or  more  performance  measures 
relating  to  fitness-for-purpose,  quality,  cycle-time, 
and  cost;  usually  requiring  the  application  of 
technology  enablers.  Reengineering  projects 
typically  take  a  minimum  of  two  years  to  complete. 

Risk  adjusted  discounted  cash  flow  -  RADCF.  A 
formal  method  of  performing  an  economic  analysis 
that  takes  the  time  value  of  money  and  investment 
risk  into  consideration. 


TMP  -  Technical  Management  Plan 

TO-BE  Model  -  Models  that  are  the  result  of 
applying  improvement  opportunities  to  the  current 
(AS-IS)  business  environment  (see  also  AS-IS 
Model). 

Total  Quality  Management/Total  Quality 
Leadership  (TQM/TQL)  -  Both  a  philosophy  and 
a  set  of  guiding  principles  that  represent  the 
foundation  of  a  continuously  improving 
organization.  TQM/TQL  is  the  application  of 
quantitative  methods  and  human  resources  to 
improve  the  material  and  services  supplied  to  an 
organization,  all  the  processes  within  an 
organization,  and  the  degree  to  which  the  needs  of 
the  customer  are  met,  now  and  in  the  future.  TQM/ 
TQL  integrates  fundamental  management 
techniques,  existing  improvement  efforts  and 
technical  tools  under  a  disciplined  approach  focused 
on  continuous  improvement. 

Unit  cost  -  The  total  costs  in  resource  and  material 
to  produce  one  instance  of  a  product  or  service. 

Value  added  activity  -  A  activity  in  a  process  that 
adds  value  to  an  output  product  or  service,  that  is, 
the  activity  merits  the  cost  of  the  resources  it 
consumes  in  production. 

Variable  cost  -  A  cost  element  that  varies  directly 
with  the  amount  of  product  or  service  produced  by 
an  activity  or  cost.  Variable  costs  go  to  zero  if  the 
activity  stops.  See  dlso  fixed  cost. 
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Doug  McDonald 
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Malcolm  Baldrige  National  Quality  Award 
National  Institute  of  Standards 
and  Technology 
Gaithersburg,  MD  20899 
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ANNEX  E.  PROCESS  IMPROVEMENT  TEAM  QUALITIES 


Characteristics  of  Effective  Teams 

■  Inspired  leadership 

■  Specific,  quantifiable  goals 

■  Commitment  and  loyalty 

■  Effective  communications 

■  Achieve  small  victories  along  the  way 

■  Think  competitively 

■  Open  minded/progressive  thinking 

■  Recognize  superior  performance 


Successful  Team  Cultural  Values 

■  Belief  in  teamwork 

■  Scientific  problem  solving  methods 

■  Respect  for  people 

■  Focus  on  customers/suppliers 

■  Belief  that  employees  want  to  do  a  good 
job 

■  Mutual  respect 

■  Continuous  process  improvement 

■  Risk  taking 

■  Coaching  to  develop  the  less  skilled 

■  Strive  for  win-win  relationships 

■  Work  to  remove  barriers 

How  to  give  constructive  feedback  in  a  team 
situation 

■  Be  descriptive 

■  Don’t  use  labels 

■  Don’t  exaggerate 

■  Speak  only  for  yourself 

■  Talk  first  about  yourself,  not  about  the 
other  person 

■  Restrict  your  feedback  to  things  you 
know  for  certain 

■  Help  people  hear  and  accept  your 
compliments  when  giving  positive 
feedback 


How  to  receive  feedback  in  a  team  situation 

■  Breath  deeply,  relax 

■  Listen  carefully  to  what  is  being  said; 
actually  hear  what  is  being  said 

■  Ask  questions  for  clarity 

■  Acknowledge  the  feedback 

■  Acknowledge  valid  points 

■  Take  time  to  sort  out  what  you  heard  (or 
think  you  heard) 


Effective  communication  guidelines 

■  Seek  self-knowledge 

■  Live  a  pattern  of  cooperation 

■  Listen  to  others  to  understand 

■  Control  the  desire  to  pass  Judgment 

■  Protect  the  other  person’s  ego 

■  Don’t:  direct,  threaten,  preach,  lecture, 
judge,  ridicule,  distract,  condescend, 
advise  without  permission,  give  false 
praise 

Team  leader  role  and  responsibibty 

■  Plan  and  orchestrate  team  activities 

■  Keep  team  focused  on  the  situation  at 
hand 

■  Promote  teamwork 

■  Establish  and  maintain  communication 
channels 

■  Coach 

■  Create  trust 


Team  member  role  and  responsibility 

■  Share  knowledge  and  expertise 

■  Attend  all  meetings 

■  Carry  out  all  assignments 

■  Participate  constructively  in  all 
discussions 

■  Understand  the  process 
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How  to  plan  a  team  meeting 

■  Determine  the  purpose  or  objective  for 
the  meeting 

■  Schedule  the  meeting  (best  times:  AM 
TYiesdays  through  Thursdays) 

■  Define  what  you  want  the  group  to  do 

■  Define  the  size  group  you  will  need 

■  Determine  who  should  attend  the 
meeting  and  why 

■  Develop  the  agenda 

■  Set  the  length  of  time  needed  to  complete 
the  agenda 

■  Decide  how  decisions  are  going  to  be 
reached 

■  Document  the  results,  action  items,  and 
assignments 


How  to  conduct  a  meeting 

■  Start  on  time 

■  Break  the  ice 

■  Make  meeting  assignments  (if  any) 

■  Review  the  agenda 

■  Review  results  of  last  meeting  (on  same 
issues) 

■  State  purpose  and  objectives  (ask:  why 
are  we  here,  and  how  will  we  know  when 
we  are  done?) 

■  Seek  contributions  and  focused 
discussion 

■  Clarify  issues  especially  if  there  is 
disagreement 

■  Keep  to  the  agenda 

■  Summarize,  assign  action  items,  close  on 
schedule 

■  Elements  of  team  conflict 

■  Frastration  caused  by  lack  of  resolution 

■  Functional  loyalties  that  inqiede 
cooperation 

■  Value,  goal,  and  methodology  differences 


■  Responsibility  issues  that  result  in  power 
struggles 

■  Status  seeking  rather  than  team  focus 


Symptoms  of  conflict 

■  Members  are  impatient 

■  Ideas  are  attacked  before  they  are 
completed 

■  Members  take  sides 

■  Comments  are  made  with  vehemence 

■  Every  suggestion  seems  impossible 

■  Grossly  divergent  ideas  of  what  to  do 

■  Expressions  of  anger  and  dislike 


Personal  conflict  resolution  principles 

■  Rationality  -  Try  to  balance  one’s  own 
emotions  with  reason 

■  Understanding  -  Try  to  understand  the 
other  party 

■  Communication  -  Consult  with  them 
before  deciding 

■  Reliability  -  Practice  personal  integrity 

■  Non-coercive  influence  -  Be  open  to 
persuasion,  try  to  persuade  them 

■  Acceptance  -  Accept  ideas  as  worthy, 
care,  and  be  willing  to  learn 

■  Goodwill  -  Do  those  things  that  are  both 
good  for  the  relationship  and  good  for 
both  parties 

How  to  build  an  effective  team' 

Affirmative  answers  to  the  questions  in  this  list 
signal  that  a  work  team  is  enjoying  good  progress 
and  is  functioning  in  an  effective  manner. 

Understanding  of  work  unit 

—  Can  members  describe  the  business  of 
their  work  unit? 

—  Do  they  know  the  general  work  flow? 

—  Are  they  aware  of  interaction  with  other 
areas  and  departments? 


Teamwork:  Involving  People  in  Quality  and  Productivity  Improvement,  Charles  A.  Aubrey,  II  and  Patricia  K. 
Felkins,  ASQC  Quality  Press,  1988.  Content™  1985,  B.  J.  Chakiris  Corporation. 
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Insight  of  work  issues  and  complexity 

—  Does  the  team  assess  the  impact  of 

proposed  changes  on  people  concerned? 

—  Do  they  understand  the  impact  on 
productivity  and  costs? 

Organization 

—  Are  minutes  taken  of  the  meeting? 

—  Does  the  team  gather  and  use  the 
resources  they  need? 

—  Is  past  progress  summarized  and  new 
action  reported? 

—  Does  the  team  plan  effectively? 

Procedures  and  norms 

—  Is  the  team  run  according  to  the  code  of 
conduct? 

—  Does  the  code  need  revision? 

—  Are  procedures  flexible? 

—  Are  procedures  appropriate  to  the  group? 

Communication 

—  Do  members  feel  comfortable  speaking 
to  the  group? 

—  Does  the  team  use  we  words? 

—  Do  members  express  their  ideas  clearly 
and  concisely? 

—  Does  the  team  communicate  through 
timely  minutes  and  reports? 

—  Does  the  group  maintain  contact  with 
management  and  other  teams? 

Participation 

—  Are  member  enthusiastic  about 
attendance? 

—  Does  everyone  participate  in  the  process? 

—  Do  members  volunteer  for  group  work? 

—  Is  the  team  making  full  use  of  group 
resources,  skills,  and  knowledge? 

Cooperation 

—  Do  team  members  help  each  other? 

—  Is  work  responsibility  spread  equally? 

—  Do  group  members  actively  support  each 
other? 

—  Are  members  open-minded  and  willing 
to  listen  to  other  ideas? 

—  Do  team  members  seem  to  like  each 
other  as  friends  and  colleagues? 


Loyalty,  identity,  and  morale 

—  Are  member  motivated? 

—  Are  members  eager  and  enthusiastic 

about  projects? 

—  Is  there  a  sense  of  cohesiveness  in  the 
group? 

—  Do  members  care  about  the  group  and 
about  each  other? 

—  Do  members  seem  to  enjoy  the  problem¬ 
solving  process? 

—  Can  the  team  accept  failure  without 
feeling  defeated? 

Responses  to  leadership 

—  Is  the  group  open  to  the  leader’s 
suggestions? 

—  Can  the  leader  influence  the  group? 

—  Does  the  team  respect  the  leader? 

Group  confidence  and  initiative 

—  Are  members  taking  the  initiative  for 
task  work  and  procedures? 

—  Do  team  members  take  responsibility  for 
organizing? 

—  Do  members  keep  the  communication 
going  without  intervention  of  the  leader? 

—  Does  the  group  feel  confident  and 
competent  in  their  task? 

—  Do  team  members  seem  satisfied  with 
the  group  decision? 

Conflict  resolution 

—  Does  the  group  recognize  and  resolve 
conflict? 

—  Do  the  members  focus  on  issues  rather 
than  personalities? 

—  Can  the  group  reach  a  compromise? 

—  Does  the  team  use  consensus? 

—  Does  the  team  gather  adequate 

information  to  understand  disputed 
issues? 

Acceptance  of  differences 

—  Do  people  listen  to  each  other? 

—  Can  differing  opinions  be  expressed 
openly? 

—  Do  members  gather  information  on  all 
sides  of  an  issue? 

—  Can  the  team  accept  criticism? 
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ANNEX  F.  PROCESS  IMPROVEMENT  AND  QUALITY  CRITERIA 


Quality,  productivity,  customer  service 
excellence,  and  process  performance  are  global 
issues.  American  and  international  standards  now 
exist  that  are  gaining  acceptance  by  all  major 
enterprises  both  public  and  private.  The  following 
subsections  provide  four  sets  of  criteria  that  can  be 
used  to  assess  and  evaluate  business  processes  and 
guide  process  improvement  efforts. 

FI.  Deming  Prize  Criteria 

The  Deming  Prize  is,  of  course,  named  after 
W.  Edwards  Deming,  one  of  the  pioneers  of  the 
quality  movement,  who  first  gained  recognition  in 
his  work  with  post- World  War  11  Japan.  Prior  to  his 
death  in  1993,  he  finally  gained  recognition  in  his 
own  country.  The  Deming  Prize  criteria  can  be 
used  as  a  guide  for  obtaining  process  and 
organizational  excellence.  Each  area  deals  with  one 
facet  of  the  process  quality  equation. 

1.0  Policy 

1 . 1  Policies  pursued  for  management,  quality,  and 
quality  control 

1 .2  Method  of  establishing  policies 

1 .3  Justifiability  and  consistency  of  policies 

1.4  Utilization  of  statistical  methods 

1 .5  Transmission  and  diffusion  of  policies 

1 .6  Review  of  policies  and  the  results  achieved 

1 .7  Relationship  between  policies  and  long-  and 
short-term  planning 

2.0  Organization  and  its  management 

2.1  Explicitness  of  the  scopes  of  authority  and 
responsibility 

2.2  Appropriateness  of  delegations  of  authority 

2.3  Interdivisional  cooperation 

2.4  Committees  and  their  activities 

2.5  Utilization  of  staff 

2.6  Utilization  of  Quality  Control  circles 

2.7  Quality  control  diagnosis 

3.0  Education  and  dissemination 

3 . 1  Education  programs  and  results 

3.2  Quality  and  control  consciousness,  degrees  of 
understanding  of  quality  control 


3.3  Teaching  and  extent  of  dissemination  of 
statistical  concepts  and  methods 

3.4  Grasp  of  the  effectiveness  of  quality  control 

3.5  Education  of  related  entities:  contractors  and 
vendors 

3.6  Quality  Control  circle  activities 

3.7  System  of  suggesting  ways  of  improvements 
and  its  actual  conditions 

4.0  Collection,  dissemination  and  use  of 

INFORMATION  ON  QUALITY 

4. 1  Collection  of  external  information 

4.2  Transmission  of  information  between 
divisions 

4.3  Speed  of  information  transmission 

4.4  Data  processing,  statistical  analysis  of 
information,  and  use  of  results 

5.0  Analysis 

5 . 1  Selection  of  key  problems  and  themes 

5.2  Propriety  of  the  analytical  approach 

5.3  Utilization  of  statistical  methods 

5.4  Linkage  with  proper  technology 

5.5  Quality  analysis,  process  analysis 

5.6  Utilization  of  analytical  results 

5.7  Assertiveness  of  improvement  suggestions 

6.0  Standardization 

6.1  Systematization  of  standards 

6.2  Method  of  establishing,  revising,  and 
abolishing  standards 

6.3  Outcome  of  the  establishment,  revision  or 
abolition  of  standards 

6.4  Contents  of  the  standards 

6.5  Utilization  of  statistical  methods 

6.6  Accumulation  of  technology 

6.7  Utilization  of  standards 

7.0  Control 

7 . 1  Systems  for  the  control  of  quality  and  related 
cost 

7.2  Control  items  and  control  points 

7.3  Utilization  of  such  statistical  control  methods 
as  control  charts 

7.4  Contribution  to  performance  of  Quality 
Control  circle  activities 
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7.5  Actual  conditions  of  control  activities 

7.6  State  of  matters  under  control 

8.0  Quality  assurance 

8. 1  Procedure  for  the  development  of  new 
products  and  services 

8.2  Safety  and  immunity  from  product  liability 

8.3  Process  design,  process  analysis,  and  process 
improvement 

8.4  Process  capability 

8.5  Instrumentation 

8.6  Equipment  maintenance  and  control  of 
purchases 

8.7  Quality  assurance  system  and  its  audit 

8.8  Utilization  of  statistical  methods 

8.9  Evaluation  and  audit  of  quality 

8.10  Actual  state  of  quality  assurance 

9.0  Results 

9. 1  Measurement  of  results 

9.2  Substantive  results  in  quality,  services, 
delivery  time,  cost 

9.3  Intangible  results 

9.4  Measures  for  overcoming  defects 

10.0  Planning  for  the  future 

10.1  Grasp  of  the  present  state  of  affairs 

10.2  Measures  for  overcoming  defects 

10.3  Plans  for  future  advances 

10.4  Linkage  with  the  long-term  plans 

F2.  Malcolm  Baldrige  National  Quality  Award 
Criteria 

The  Baldrige  Award  is  administered  by  the 
National  Institute  of  Standards  and  Technology.^ 
Legislation  creating  the  award  was  enacted  in  1987 
as  Public  Law  100-107  in  recognition  of  the  fact 
that  quality  had  become  a  matter  of  national 
strategic  importance.  The  purpose  of  the  award, 
named  after  the  late  Secretary  of  Commerce,  is  to 
help  the  United  States  improve  quality  and 
productivity  by: 

■  Stimulating  companies  to  attain  excellence  for 
the  pride  of  achievement 


■  Recognizing  outstanding  companies  to  provide 
examples  to  others 

■  Establishing  guidelines  that  business, 
governmental,  and  other  organizations  can  use 
to  evaluate  and  improve  their  own  quality 
efforts 

■  Providing  information  from  winning 
companies  on  how  to  mange  for  superior 
quality. 

The  categories  below  are  from  the  1992 

criteria  and  are  shown  with  weighting  factors: 

1.0  Leadership  (9%) 

1 . 1  Senior  executive  leadership 

1 .2  Management  for  quality 

1.3  Public  responsibility 

2.0  Information  and  analysis  (8%) 

2. 1  Scope  and  management  of  quality  data  and 
information 

2.2  Competitive  comparisons  and  benchmarks 

2.3  Analysis  and  uses  of  company-level  data 

3.0  Strategic  quality  planning  (6%) 

3.1  Strategic  quality  and  company  performance 
plaiming  process 

3.2  Quality  and  performance  plans 

4.0  Human  resource  development  and 
management  (15%) 

4.1  Human  resource  management 

4.2  Employee  involvement 

4.3  (Ju^ty  education  and  training 

4.4  Employee  performance  and  recognition 

4.5  Employee  well-being  and  morale 

5.0  Management  of  process  quality  (14%) 

5.1  Design  and  introduction  of  quality  products 
and  services 

5.2  Process  management — ^product  and  service 
production  and  delivery  processes 


2  The  Corporate  Guide  to  the  Malcolm  Baldrige  National  Quality  Award,  Marion  Mills  Steeples,  ASQC  Quality 

Press,  1993. 
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5.3  Process  management — ^business  processes  and 
support  services 

5.4  Supplier  quality 

5.5  QuaJity  assessment 

6.0  Quality  and  operational  results  (18%) 

6. 1  Product  and  service  quality  results 

6.2  Company  operational  results 

6.3  Business  process  and  support  service  results 

6.4  Supplier  quality  results 

7.0  Customer  focus  and  satisfaction  (30%) 

7.1  Customer  relationship  management 

7.2  Commitment  to  customers 

7.3  Customer  satisfaction  determination 

7.4  Customer  satisfaction  results 

7.5  Customer  satisfaction  comparison 

7.6  Future  requirements  and  expectations  of 
customers 

F3.  ISO  9000/ASQC  9000  Criteria 

ISO  is  the  International  Organization  for 
Standardization,  and  its  objective  is  to  promote  the 
development  of  standards,  testing,  and  certification 
in  order  to  encourage  the  trade  of  goods  and 
services.^  The  organization  consists  of 
representatives  from  91  countries.  The  American 
National  Standards  Institute  (ANSI)  represents  the 
United  States  in  this  body.  America  participates  in 
the  writing  of  ISO  9000  standards  through  the  U.S. 
Technical  Advisory  Group  (TAG),  administered  by 
the  American  Society  for  Quality  Control  (ASQC). 

ISO  9000  is  a  series  of  five  international 
standards  on  quality  management  and  assurance. 
ISO  90(X)  supplier  certification  is  fast  becoming  a 
requisite  for  participating  in  international  trade. 
DoD  is  in  the  process  of  supplanting  military 
quality  standards  (MIL-Q  9858A)  with  ISO  9000. 


The  following  list  of  categories  is  covered  in 
one  or  more  ISO  9000  documents.  The  actual 
standards  can  be  obtained  from  ANSI,  11  West  42nd 
St.,  13th  Floor,  New  York,  NY  10036  (212)  642- 
4900. 

■  Management  responsibility 

■  Quality  system 

■  Product  identification  and  traceability 

■  Inspection  status 

■  Inspection  and  testing 

■  Inspection,  measuring,  and  test 
equipment 

■  Control  of  non-conforming  product 

■  Handling,  storage,  packaging,  and 
delivery 

■  Document  control 

■  Training 

■  Statistical  techniques 

■  Internal  auditing 

■  Contract  review 

■  Purchasing 

■  Process  control 

■  Purchaser  supplied  product 

■  Corrective  action 

■  Design  control 

■  Servicing. 

F4.  Process  Improvement  Levels  (Harrington) 

H.  James  Harrington  promulgates  a  system  of 
process  assessment  and  qualification  with 
designations  ranging  from  unknown  status  to  world- 
class^  .  Each  higher  level  includes  the  qualifications 
of  all  lower  levels. 


3  ISO  9000,  Greg  Hutchins,  Oliver  Wight  Publications,  1993. 

4  Business  Process  Improvement,  H.  James  Harrington,  McGraw  Hill,  1991,  chapter  8. 


Process  Improvement  and  Quality  Criteria 


F-3 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


LEVEL  STATUS 

DE^RIFTION 

6 

Unknown 

Process  status  has  not  been  determined 

5 

Understood 

Process  design  is  understood  and  operates  according 
to  prescribed  documentation 

4 

Effective 

Process  is  systematically  measured,  streamlining  has 
started  and  end-customer  expectations  are  met 

3 

Efficient 

Process  is  streamlined  and  is  more  efficient 

2 

Error-free 

Process  is  highly  effective  (error-free)  and  efficient 

1 

World-class 

Process  is  world-class  and  continues  to  improve 

The  following  tables  show  the  improvement 
path  from  level  6  to  level  1  for  each  of  the  above 
categories.  Note  that  to  achieve  a  new  level  of 
performance,  that  level’s  requirements  and  all 
previous  level’s  requirements  must  be  met. 


Eight  process  categories  are  examined  to 
determined  the  qualification  level  of  the  functional 
process  under  study: 

■  Customer  related  measurements 

■  Process  measurements  and/or 
performance 

■  Supplier  partnerships 

■  Documentation 

■  Training 

■  Benchmarking 

■  Process  adaptability 

■  Continuous  improvement. 


The  terms  requirements,  expectations,  and 
desires  reflect  a  progression  of  ever  increasing 
performance  with  desires  being  the  highest  possible 
attainment. 
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■  ■=  •• 

Measurements  reflect  the  end-customer’s  view  of  the  process 

Customer  REQUIREMENTS  are  documented 

Customer  feedback  system  is  established 

■  ■■■  ■ 

Customer  effectiveness  charts  are  posted  and  updated 

Customer  REQUIREMENTS  are  met 

Customer  EXPECTATIONS  are  documented 

■H 

Customer  EXPECTATIONS  are  met 

Challenge  targets  are  set  by  the  process  improvement  team  (PIT) 

Customer  EXPECTATIONS  are  updated 

Performance  for  the  last  six  months  never  fell  below  customer  EXPECTATIONS 

Trend  lines  show  continuous  improvement 

World-class  targets  are  established 

Customers  are  invited  to  regular  performance  reviews 

Customer  DESIRES  are  understood 

:;,  v 

Customer  expectation  targets  are  regularly  updated  and  always  exceeded 

World-class  measurements  are  met  for  a  minimum  of  three  consecutive  months 

Many  of  the  customer  DESIRES  are  met 
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ProcfiM  MaMrenienis  amVte 

Overall  effectiveness  and  efficiency  are  measured  and  posted  where  they  can  be 
seen  by  employees 

Effectiveness  and  efficiency  targets  are  set 

;  \:;=:  • 

Process  operation  and/or  control  weaknesses  are  evaluated  and  meet  minimum 
requirements 

HPH 

Overall  effectiveness  targets  are  met  and  challenge  targets  are  established 

Cost  of  poor  quality  measurements  are  developed 

HIH 

Some  internal  efficiency  measurements  are  established 

1  ^  . 

Internal  effectiveness  measurements  and  targets  are  50%  complete  and  posted 

Overall  process  cycle  time  and  cost  are  defined 

No  significant  effectiveness,  efficiency,  or  control  exposures  exist 

mum 

Substantial  improvement  activities  are  under  way 

Im^HB 

There  is  a  significant  improvement  in  product  quality  cost 

HHIbH 

HHIP 

Internal  effectiveness  and  efficiency  measurements  are  in  place  and  are  posted, 
with  targets  set  by  the  affected  areas 

There  is  a  significant  reduction  in  cycle  time  and  bureaucracy 

Overall  efficiency  targets  are  met 

Most  measurements  show  an  improvement  trend 

II— 

Key  process  control  points  are  identified 

Tangible,  measurable  results  are  realized 
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Uv»t 

ProcNBSS^leasuremea^  P^orman^ 

All  measurements  show  an  Improvement 

Benchmark  targets  are  defined  for  external  customers  and  critical  in-process  activities 

k  ' 

II 

In-process  control  charts  are  implemented  as  appropriate,  and  the  process  is 
under  statistical  control 

Feedback  systems  are  in  place  close  to  the  point  at  which  the  work  is  being  done 

Most  measurements  are  made  by  the  person  doing  the  job 

There  is  tangible  and  measurable  improvement  in  the  in-process  measurements 

No  operational  inefficiencies  are  anticipated 

An  independent  audit  plan  is  in  place  and  working 

The  process  is  error-free 

’ 

AN  measurements  exceed  those  of  the  benchmark  company  for  three  months 

Effectiveness  measurements  indicate  that  the  process  is  error-free  for  all  customer 
and  in-process  control  points 
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Process«Me^reiiieiits  andfor  Perforinance 


All  suppliers  are  identified 


Meetings  are  held  with  critical  suppliers,  and  agreed-to  input 
REQUIREMENTS  are  documented 


Feedback  systems  to  critical  suppliers  are  in  place 


Meetings  are  held  with  all  suppliers,  and  agreed-to  input  REQUIREMENTS 
are  documented 


All  critical  suppliers  meet  input  REQUIREMENTS 


All  supplier  inputs  met  requirements  for  the  last  three  months 


Regular  meetings  are  held  to  ensure  that  suppliers  understand  the  changing 
needs  and  EXPECTATIONS  OF  THE  PROCESS 


All  suppliers  meet  process  EXPECTATIONS 


All  suppliers  meet  process  requirements  for  a  minimum  of  six  months 


Process  Improvement  and  Quality  Criteria 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


iiiiiliiiii 


Process  is  defined  and  modeied  with  activity  and  data  models _ _ 


Model  accuracy  is  verified  _ _ 


Documentation  is  followed 


Process  improvement  team  members  and  process  owners  are  named _ 


Process  improvement  team  mission  is  documented _ _ 


Process  boundaries  are  defined  (enterprise  model) _ 


Process  is  modeled  and  documents  are  updated  _ 


Overall  process  is  fully  documented  _ 


Subprocesses  are  documented  _ _ 


Training  requirements  are  documented 


Software  controls  are  in  place 


The  readability  level  of  all  documents  is  at  a  grade  level  less  than  the  minimum 
education  of  the  people  using  them  _ 


Employees  understand  their  job  descriptions 


Change  level  controls  are  in  place  _ 


Documents  are  systematically  updated  _ 


All  documents  meet  world-class  standards  for  the  process  being  improved 
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LbiibI' 

Traifiir^ 

Process  improvement  team  is  trained  in  the  basic  techniques  and  tools 
and  the  fundamental  functional  process  improvement  techniques 

"  ■  ■  ■■ \ 

In-process  training  needs  are  evaluated  and  documented 

i-; 

Resources  are  assigned  to  support  training  needs 

In-process  job  training  procedures  are  developed  for  all  critical  activities 

People  are  assigned  to  conduct  job  and  process  training 

Process  improvement  team  is  trained  in  statistical  process  control 

All  people  performing  critical  jobs  are  trained  in  the  nevr  procedures,  including 

job-related  training 

h 

In-process  job  training  procedures  are  developed  for  all  activities 

f ^ 

Plans  are  in  place  to  train  all  employees  who  are  part  of  the  process  team  in 
methods  and  problem-solving  techniques 

Process  improvement  team  members  understand  one  or  more  sophisticated 
techniques  used  in  process  improvement  actions 

^  ^  "r» 

All  employees  in  the  process  receive  training  on  the  total  process  operation 

..  . .ite."""  :s-  ’••••  . 

All  employees  in  the  process  are  trained  and  scheduled  for  refresher  courses 

Employee  evaluation  of  their  training  process  is  complete  and  the  training  meets 
all  employee  REQUIREMENTS 

Team  and  problem-solving  courses  are  complete  and  employees  are  meeting 
regularly  to  solve  problems 

Employees  are  regularly  surveyed  to  define  additional  training  needs  and  new 

training  programs  are  implemented  based  on  these  surveys 
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luevet 

Benciiiiii^ng 

Not  required 

^  I 


iBUBi 


Plan  exists  to  benchmark  customer  requirements 


Customer  REQUIREMENTS  are  benchmarked 


Plan  exists  to  benchmark  critical  activities 


Plan  exists  to  benchmark  the  process 


Process  is  benchmarked  and  targets  are  assigned 


Process  improvement  team  understands  the  keys  to  the  benchmark  organization’s 
performance 


Ongoing  benchmarking  pian  is  implemented 
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Levirt 

Process  Aciaptabillty 

5 

Not  required 

4 

Data  are  collected  that  identify  problems  with  present  process  adaptability 

Employees  are  trained  to  distinguish  how  far  they  can  deviate  from  the  established 
procedures  to  meet  a  customer’s  special  needs 

Future  process  change  requirements  are  projected 

-J:-'  . 

A  proactive  internal  and  external  customer  complaint  system  is  established 

The  customer  reviews  the  process  change  plan  and  agrees  that  it  meets  his  or  her 

needs  of  the  strategic  period 

2 

Employees  are  empowered  to  provide  the  required  emergency  help  to  their 
customers  and  are  measured  accordingly 

Resources  are  committed  to  satisfy  future  customer  needs 

Process  adaptability  complaints  are  significantly  reduced 

In  the  last  six  months,  no  customers  complained  that  the  process  did  not  meet 

their  needs 

Present  process  handles  the  exceptions  better  than  the  benchmark  company’s 
process 
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L»«dl 

Continuous  Improvement 

. ■ 

Basics  of  functional  process  improvement  are  in  place 

All  major  exposures  are  identified  and  action  plans  are  in  place 

A  detailed  plan  to  improve  the  process  to  level  4  is  agreed  to  and  funded 

A  process  is  operational  and  control  weaknesses  are  assessed  and  deemed 

containable 

i--- 

A  plan  for  improving  the  process  to  level  3  is  prepared,  approved  and  funded 

The  process  philosophy  accepts  that  people  make  mistakes,  provided  everyone 
works  relentlessly  to  find  and  remove  causes  of  errors 

Hll  1 

A  plan  to  Improve  the  process  to  level  2  is  developed,  approved,  and  funded 

The  process  philosophy  evolves  to  the  point  at  which  errors  are  unacceptable. 

Everyone  works  relentlessly  to  prevent  errors  from  occurring  even  once 

illH 

Surveys  of  the  employees  show  that  the  process  is  easier  to  use 

Plans  to  improve  the  process  to  level  1  are  prepared,  approved,  and  funded 

An  independent  audit  verifies  world-class  status 

Plans  are  approved  and  in  place  to  become  even  better 
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ANNEX  G.  DoD  QUALITY  AND  PRODUCTIVITY  SELF-ASSESSMENT  GUIDE 

This  assessment  instrument  is  related  to  task  6.1.2.  Please  see  this  section  of  the  guidebook  for 
additional  information  about  the  instrument.  This  assessment  should  take  about  15  minutes  to  complete 
with  an  additional  15  minutes  to  score. 

Organizational  Climate 

There  are  70  statements  in  this  part  of  the  self-assessment  guide.  Respond  to  each  with  the  number  that 
indicates  the  extent  of  your  agreement  with  the  statement: 

1  -  Strongly  Disagree  4  -  Somewhat  Agree 

2  -  Disagree  5  -  Agree 

3  -  Somewhat  Disagree  6  -  Strongly  Agree 

1 .  _  People  in  this  organization  are  aware  of  its  overall  mission. 

2.  _  In  general,  this  organization’s  customers  believe  that  we  care  about  what  they  think. 

3.  _  People  in  this  organization  are  aware  of  how  their  jobs  contribute  to  the  organization’s  mission. 

4.  _  It’s  in  everyone’s  best  interests  that  this  organization  be  successful. 

5.  _  People  in  this  organization  are  aware  of  how  the  organization’s  mission  contributes  to  higher- 

level  missions  and  objectives. 

6.  _  In  general,  this  organization’s  customers  would  not  go  elsewhere  if  it  were  possible. 


People  in  this  organization: 

7.  _  Try  to  plan  ahead  for  changes  (such  as  in  policy)  that  might  impact  our  mission  performance 

8.  _  Try  to  plan  ahead  for  technological  changes  (such  as  new  developments  in  computer  software) 

that  might  impact  our  mission  performance 

9.  _  Regularly  work  together  to  plan  for  the  future 

10.  _  See  continuing  improvement  as  essential. 
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1  -  Strongly  Disagree 

2  -  Disagree 

3  -  Somewhat  Disagree 


4  -  Somewhat  Agree 

5  -  Agree 

6  -  Strongly  Agree 


11. 

12. 

13. 

14. 

15. 

16. 

17. 

18. 


People  in  this  organization  care  about  what  will  happen  to  the  organization  after  they  are 
reassigned 

Creativity  is  actively  encouraged  in  this  organization. 

Innovators  are  the  people  who  get  ahead  in  this  organization. 

The  quality  of  our  work  is  second  only  to  mission  accomplishment  as  the  overriding  focus  of 
this  organization. 

Every  member  of  this  organization  is  concerned  with  the  need  for  quality  management. 

Continuous  quality  improvements  within  this  organization  can  lead  to  more  productive  use  of 
our  resources. 

People  in  this  organization  know  how  to  define  the  quality  of  what  we  do. 

Every  member  of  this  organization  needs  to  contribute  to  quality  improvement. 


People  in  this  organization: 

19.  _  Live  up  to  high  ethical  standards 

20.  _  Like  to  do  a  good  job 

21 .  _  Emphasize  doing  things  right  the  first  time. 


The  leader (s)  in  this  organization  (people  at  the  highest  level): 


22. 

23. 

24. 

25. 

26. 

27. 

28. 


Are  conunitted  to  providing  top-quality  services/products/work 
Regularly  review  the  quality  of  work  produced 
Ask  people  about  ways  to  improve  the  work  produced 
Follow  up  suggestions  for  improvement 

Set  examples  of  quality  performance  in  their  day-to-day  activities 

Regularly  review  the  organization’s  progress  toward  its  goals  and  objectives 

Attempt  to  find  out  why  the  organization  may  not  be  meeting  a  particular  goal/objective. 
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1  -  Strongly  Disagree  4  -  Somewhat  Agree 

2  -  Disagree  5  -  Agree 

3  -  Somewhat  Disagree  6  -  Strongly  Agree 

People  in  my  work  unit: 

29.  _ _  Turn  to  their  supervisors  for  advice  about  how  to  improve  their  work 

30.  _  Know  their  supervisors  will  help  them  find  answers  to  problems  they  may  be  having 

3 1 .  _  Are  challenged  by  their  supervisors  to  find  ways  to  improve  the  system. 


32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

40. 

41. 

42. 

43. 


The  supervisors  in  my  work  unit  make  continuous  improvement  of  our  work  top  priority. 

The  supervisors  in  my  work  unit  regularly  ask  our  customers  about  the  quality  of  work 
they  receive. 

The  structure  of  our  organization  makes  it  easy  to  focus  on  quality. 

The  way  we  do  things  in  this  organization  is  consistent  with  quality. 

People  in  my  work  unit  understand  how  a  quality  emphasis  leads  to  more  productive  use 
of  resources. 

People  in  my  work  unit  can  describe  the  organization’s  quality  and  productivity  policy. 

People  in  my  work  unit  believe  that  quality  and  productivity  improvement  are  their  responsibility. 
People  in  my  work  unit  take  pride  in  their  work. 

People  in  my  work  unit  share  responsibility  for  the  success  of  failure  of  our  services/products. 

People  in  my  work  unit  believe  that  their  work  is  important  to  the  success  of  the 
overall  organization. 

We  have  good  relationships  between  departments  in  this  organization. 

Co-workers  in  this  organization  cooperate  with  each  other  to  get  the  job  done. 
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1  -  Strongly  Disagree  4  -  Somewhat  Agree 

2  -  Disagree  5  -  Agree 

3  -  Somewhat  Disagree  6  -  Strongly  Agree 

44.  _  A  spirit  of  cooperation  and  teamwork  exists  in  this  organization. 

45.  _  We  have  good  relationships  with  other  organizations  that  we  work  with. 

46.  _  Supervisors  in  my  work  unit  request  employee  opinions  and  data. 

47.  _  People  in  my  work  unit  are  involved  in  improving  our  services/products/work. 

48.  _  We  have  the  appropriate  personnel  in  my  work  unit  to  get  the  job  done  properly. 

49.  _  The  work  goals  or  standards  in  my  work  unit  are  generally  fair. 

50.  _  Thesupervisorsinmy  work  unit  do  a  goodjob  of  setting  work  expectations. 

51.  _  People  in  my  work  unit  are  friendly  with  one  another. 

52.  _  People  in  my  work  unit  enjoy  their  co-workers. 

53.  _  We  have  the  right  tools,  equipment,  and  materials  in  my  work  unit  to  get  the  job  done. 

54.  _  The  materials  and  supplies  we  need  in  my  work  unit  are  delivered  on  time  as  ordered. 

55.  _  The  distribution  of  work  among  the  people  in  my  work  unit  is  well  balanced. 

56.  _  In  my  work  unit,  we  have  enough  time  to  perform  our  jobs  in  a  professional  manner. 

57.  _  My  work  unit  is  structured  properly  to  get  the  job  done. 

In  my  work  unit: 

58.  _  People  are  rewarded  to  get  the  job  done 

59.  _  People  are  paid  fairly  for  the  work  they  do 

60.  _  Attempts  are  made  to  promote  the  people  who  do  good  work. 
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1  -  Strongly  Disagree  4  -  Somewhat  Agree 

2  -  Disagree  5  -  Agree 

3  -  Somewhat  Disagree  6  -  Strongly  Agree 

In  my  work  unit: 

61.  _  People  receive  promotions  because  they  earned  them 

62.  _  Supervisors  give  credit  to  people  when  they  do  a  good  job 

63.  _  There  are  penalties  for  people 

64.  _  People  are  given  quick  recognition  for  outstanding  performance 

65.  _  People  know  who  their  customers  are 

66.  _  People  care  about  our  customers 

67.  _  There  are  effective  communication  channels  between  departments  in  this  organization 

68.  _  People  do  not  have  to  rely  on  the  grapevine  or  ramors  for  information 

69.  _  People  have  ample  opportunity  to  exchange  information  with  their  supervisors 

70.  _  People  get  the  facts  and  the  information  they  need  to  do  a  good  job. 
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Assessment  of  Process 

There  are  101  statements  in  this  section.  Circle  the  answer  that  most  closely  represents  your  perception  of 
your  organization. 

Yes  No  Hoi 

Sure  This  organization  has: 

71.  2  1  1  Surveyed  some/all  of  its  members  in  order  to  determine  whether  improvements 

in  quality  are  needed. 

72.  2  1  1  Used  formal  interviews  with  some/all  of  its  members  in  order  to  determine 

whether  improvements  in  quality  are  needed. 

73.  2  1  1  Informally  asked  some/all  of  its  members  for  their  opinions  about  whether 

improvements  in  quality  are  needed. 

74.  2  1  1  Asked  senior  management  for  their  opinions  about  whether  improvements  in 

quality  are  needed. 

75.  2  1  1  Analyzed  data  concerning  goal/objective  accomplishments  in  order  to  determine 

whether  improvements  in  quality  are  needed. 

76.  2  1  1  Relied  on  higher-level  directives  in  order  to  determine  whether  improvements 

in  quality  are  needed. 

77.  2  1  1  Asked  established  team  members  to  report  periodically. 

This  organization  is  or  might  become  committed  to  quality 
improvement  because: 

78.  2  1  1  We  are  mandated  to  do  so  by  a  higher  authority. 

79.  2  1  1  The  people  at  the  top  level  of  this  organization  are/were  dissatisfied  with  the 

quality  being  achieved. 

80.  2  1  1  We  want  to  improve  an  already  acceptable  quality  record. 

81.2  1  1  We  want  to  maintain  a  specified  level  of  service  in  the  face  of  budget  reductions. 

82.  2  1  1  The  people  we  serve  deserve  our  best  efforts. 


G-6 


DoD  Quality  and  Productivity  Self-Assessment  Guide 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


Nq 

Don’t 

Havp 

This  organization  has  a  quality  improvement  policy  that: 

83. 

2 

1 

1 

Is  written 

84. 

2 

1 

1 

Has  specific  goals  and  objectives 

85. 

2 

1 

1 

Everyone  in  the  organization  has  seen 

86. 

2 

1 

1 

Is  taken  seriously  by  people 

87. 

2 

1 

1 

Holds  people  accountable  for  success/failure. 

Ysi 

Ne 

NA 

Responsibility  for  quality  improvement: 

88. 

2 

1 

1 

Is  accepted  by  senior  management 

89. 

2 

1 

1 

Is  accepted  by  middle  management 

90. 

2 

1 

1 

Is  accepted  by  almost  all  organizational  members. 

91. 

2 

1 

1 

This  organization  has  a  separately  identified  office  that  oversees  its 
quality  improvement  efforts. 

92. 

2 

1 

1 

Quality  improvement  concerns  are  discussed/monitored  at  least  on  a 
quarterly  basis. 

93. 

2 

1 

1 

Managers  at  all  levels  have  clearly  defined  roles  in  our  quality  improvement 
process. 

94. 

2 

1 

1 

This  organization  uses  teams  to  monitor  quality  improvement  projects. 

95. 

2 

1 

1 

Managers  at  all  levels  are  responsible  for  the  success  or  failure  of  our  quality 
improvement  efforts. 

96. 

2 

1 

1 

This  organization  has  a  data  base  or  tracking  system  for  relevant  quality 
information. 

Yes 

No 

NA 

In  order  to  determine  what  our  customers  think  about  our  products/ 
services,  we: 

97. 

2 

1 

1 

Conduct  surveys  on  a  regular  basis 

98. 

2 

1 

1 

Ask  customers  informally 

99. 

2 

1 

1 

Monitor  complaints 

100. 

2 

1 

1 

Ask  our  employees  who  have  contact  with  our  customers. 

DoD  Quality  and  Productivity  Self-Assessment  Guide 


G-7 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


Yes  No  NA  The  leaders  at  the  top  level  in  this  organization: 


101.  2  1  1 

102.  2  1  1 

103.  2  1  1 

104.  2  1  1 


Have  agreed  upon  a  definition  of  quality  improvement 
Have  set  long-term  goals  concerning  quality  improvement 
Have  set  short-term  goals  concerning  quality  improvement 
Have  defined  performance  measures  to  monitor  progress  toward 
reaching  objectives  and  goals. 


1  -  Almost  None  4  -  Quite  a  Few 

2  -  Very  Few  5  -  Most 

3  -  Some  6  -  Almost  All 

How  many  work  units  within  this  organization: 

105.  _  Know  how  the  organization  defines  quality  improvement 

106.  _  Have  set  long-term  goals  concerning  quality  improvement 

107.  _  Have  set  short-term  objectives  concerning  quality  improvement 

108.  ^  Have  defined  performance  measures  to  monitor  progress  toward  reaching  their  objectives 

and  goals? 


How  many  organizational  members: 

109.  _  Can  specify,  if  asked,  what  goals  or  objectives  they  are  working  on 

1 10.  _  Were  invited  to  participate  in  setting  goals  or  objectives  related  to  their  work 

111.  _  Know  how  the  goals/objectives  they  are  working  toward  relate  to  their  work  unit’s  mission 

112.  _  Know  how  performance  measures  relate  to  monitoring  their  accomplishment  of  goals  and 

objectives? 


Yes  No  NA 

113.  2  1  1 

114.  2  1  1 

115.  2  1  1 


Long-range  planning  in  this  organization  includes: 
Integration  of  quality  improvements 
Prioritizing  quality  improvement  issues 
Customer  input. 
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Yes  No  NA  Long*range  planning  in  this  organization  includes: 

116.  2  1  1  Employee  input 

117.  2  1  1  Quality  improvement  implementation  strategies  for  all  work  units 

118.  2  1  1  A  means  for  monitoring  quality  improvement  progress  over  time. 

Yes  No  NA  In  terms  of  setting  organizational  improvement  priorities,  we  have 

considered  or  evaluated: 

119.  2  1  1  Changing  our  business  strategy 

120.  2  1  1  Improving  our  work  methods  or  procedures 

121.  2  1  1  Improving  our  employee  utilization 

122.  2  1  1  Revising  or  instituting  training  programs 

123.  2  11  Acquiring  recent  technological  improvements  (equipment,  etc). 

1  -  Strongly  Disagree  4  -  Somewhat  Agree 

2  -  Disagree  5  -  Agree 

3  -  Somewhat  Disagree  6  -  Strongly  Agree 

124.  _  The  structure  of  this  organization  supports  its  efforts  to  carry  out  its  mission. 

125.  _  Organizational  members  have  the  information  they  need  to  do  their  work. 

126.  _  This  organization  has  a  realistic  schedule  for  replacing  outdated  equipment. 

127.  _  This  organization’s  members  have  been  adequately  trained  to  use  the  equipment  they  have. 

128.  _  Before  equipment  is  bought  by  or  issued  to  this  organization,  plans  have  been  made  concerning 

how  it  will  be  used  and  who  will  use  it. 

129.  _  Efforts  are  made  to  update  work  methods  in  this  organization. 
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1  -  Strongly  Disagree  4  -  Somewhat  Agree 

2  -  Disagree  5  -  Agree 

3  -  Somewhat  Disagree  6  -  Strongly  Agree 

1 30.  _  People  in  charge  of  similar  work  units  frequently  share  information  about  their  work  methods 

and  practices. 

131.  _  Updating  work  methods  can  be  key  to  quality  improvement. 


Organization  members  with  good  ideas  are  likely  to: 

132.  _  Formally  submit  them  through  a  suggestion  system 

133.  _  Tell  their  supervisors 

134.  _  Be  asked  periodically  what  they  think. 


N2 

NA 

135. 

2 

1 

1 

This  organization  has  a  suggestion  program. 

136. 

2 

1 

1 

This  organization  has  conducted  brainstorming  sessions  that  included  lower  level 
organizational  members. 

137. 

2 

1 

1 

This  organization  has  used  teams  to  gather  information  or  solve  problems. 

1  -  Strongly  Disagree  4  -  Somewhat  Agree 

2  -  Disagree  5  -  Agree 

3  -  Somewhat  Disagree  6  -  Strongly  Agree 

138.  _  Creative  thinking  is  rewarded  in  this  organization. 

139.  _  Taking  risks  is  rewarded  in  this  organization. 

140.  _  Managers  at  all  levels  have  the  authority  to  try  promising  new  approaches. 

141.  _  A  promising  new  approach  is  likely  to  be  approved  quickly  for  a  trial. 

142.  _  The  future  strength  of  this  organization  is  dependent  on  the  continuing  growth  of  its  members 

through  appropriate  training. 
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Circle  the  response  number  next  to  the  one  statement  that  best  represents  your  organization. 

With  respect  to  setting  goals  or  expectations  for  their  work,  most  non-supervisory  members: 

143.  6  Have  direct  input 

4  Have  indirect  input  through  representatives 

3  Can  negotiate  with  management 
1  Have  no  input. 

To  learn  about  quality  management  techniques,  most  organizational  members: 

144.  6  Attend  mandatory  in-house  training  programs 

5  Attend  in-house  training  programs  on  a  voluntary  basis 

4  Attend  outside  seminars 

3  Review  available  in-house  resources  (books  and  tapes) 

1  None  of  the  above. 


Yes 

NA 

In  order  to  tell  how  weU  we  are  doing,  we  monitor: 

145. 

2 

1 

1 

Our  efficiency 

146. 

2 

1 

1 

Our  effectiveness 

147. 

2 

1 

1 

Our  productivity 

148. 

2 

1 

1 

The  quality  or  our  services/products/work 

149. 

2 

1 

1 

The  timeliness  of  our  work 

150. 

2 

1 

1 

Our  innovativeness 

Yes 

m. 

NA 

In  order  to  tell  how  well  we  are  doing,  we  monitor: 

151. 

2 

1 

1 

The  quality  of  working  life  for  our  members 

152. 

2 

1 

1 

Our  finances. 

The  performance  data  that  this  organization  collects: 

153. 

2 

1 

1 

Are  tracked  over  time 

154. 

2 

1 

1 

Are  compared  with  goals,  standards,  or  objectives 

155. 

2 

1 

1 

Are  compared  with  data  from  other  similar  organizations 

156. 

2 

1 

1 

Are  evaluated  at  least  quarterly 

157. 

2 

1 

1 

Are  used  to  identify  problems^a^^ers 

158. 

2 

1 

1 

Are  evaluated  by  a  team  or  task  force 

159. 

2 

1 

1 

Are  used  to  identify  opportunities  for  improvement. 
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Yes  No  NA 
160.  2  1  1 


161.  2  1  1 

162.  2  1  1 

163.  2  1  1 

164.  2  1  1 

165.  2  1  1 


166.  2  1  1 

167.  2  1  1 

168.  2  1  1 

169.  2  1  1 

170.  2  1  1 

171.  2  1  1 


Organizational  members  are  informed  about  how  this  work  unit  stands  in  relation 
to  goals,  objectives,  or  standards? 

Top  performing  managers  at  all  levels  in  this  organization  can  expect: 

A  monetary  bonus  or  award 
An  award 

To  be  recognized  by  leaders  at  the  top  level 
To  be  told  they  are  doing  a  great  job 
Increased  responsibility. 

Top  performing  organizational  members  can  expect: 

A  monetary  bonus  or  award 
An  award 

To  be  recognized  by  leaders  at  the  top  level 
To  be  told  they  are  doing  a  great  job 
Increased  responsibility. 

The  performance  appraisals  of  manager  at  all  levels  include  quality  improvement 
criteria. 


172.  2 


The  performance  appraisals  of  organizational  members  include  quality 
improvement  criteria. 
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Management  Tools  Assessment 
There  are  21  statements  in  this  section. 

Yes  No  NA  This  organization  has  used  surveys  to: 

173.  2  11  Assess  employees’  opinion  about  the  organization’s  practices  or  policies 

174.  2  1  1  Gather  information  about  what  in  the  organization  needs  improving 

175.  2  11  Assess  the  outcomes  of  its  work 

176.  2  1  1  Assess  the  quality  of  its  woik 

177.  2  11  Assess  employee  opinions  about  the  goals/objectives  they  are  working  toward. 

This  organization  has  called  groups  of  individuals  together  to: 

178.  2  11  Define  or  clarify  the  organization’s  mission  and/or  work 

179.  2  1  1  Define  long-term  organizational-level  goals  and/or  long-term  work  unit-level  goals 

180.  2  1  1  Define  short-term  organizational  objectives  and/or  short-term  work  unit  objectives 

181.  2  1  1  Identify  obstacles  to  goal/objective  accomplishment 

182.  2  1  1  Define  performance  measures  to  track  progress  toward  goal  attainment. 

183.  2  1  1  The  organization  uses  statistical  process  control  charts  or  graphs  to  track  data 

over  time. 

184.  2  1  1  This  organization  uses  diagrams  or  flowcharts  to  highlight  potential  causes 

of  problems. 

185.  2  1  1  This  organization  has  evaluated  its  office  and  work  space  design. 

186.  2  11  This  organization  has  a  high-quality  information  resource  library. 
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Mq  NA 


187.  2 


This  organization  has  arranged  workshops  to  promote  quality  management 
awareness  among  its  members. 


Hq 

NA 

This  organization  has: 

188. 

2 

1 

1 

Published  newsletters  containing  quality  improvement  information 

189. 

2 

1 

1 

Posted  information  about  quality  improvement  on  bulletin  boards 

190. 

2 

1 

1 

Held  contests  to  reward  the  most  improved  work  units 

191. 

2 

1 

1 

Attempted  to  inform  and  involve  everyone  in  quality  improvement 

192. 

2 

1 

1 

Used  team-building  techniques  to  improve  relationships 

193. 

2 

1 

1 

Established  improvement  teams. 
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Organizational  Assessment 
There  are  22  statements  in  this  section. 

1  -  Strongly  Disagree  4  -  Somewhat  Agree 

2  -Disagree  5 -Agree 

3  -  Somewhat  Disagree  6  -  Strongly  Agree 

194.  _  Work  delays  are  uncommon  in  this  organization. 

195.  _  Once  a  job  or  project  gets  started,  it’s  usually  finished  without  undue  delay. 

196.  _  There  is  little  waste  of  materials  and  supplies. 

197.  _  People  make  efforts  to  reuse  or  salvage  excess  materials  and  supplies  whenever  possible. 

198.  _  Tools  and/or  equipment  are  maintained  and  operated  at  peak  efficiency. 

199.  _  Our  tools  and/or  equipment  rarely  require  repair. 

200.  _  This  organization  has  sufficient  personnel  to  accomplish  its  mission. 

201.  _  The  personnel  turnover  rate  is  low. 

202.  _  Working  conditions  (noise,  heat,  light,  cleanliness)  are  excellent. 

203.  _  Work  facilities  are  excellent. 

204.  _  Organizational  members  are  well  trained. 

205.  _  Organizational  members  receive  the  guidance  and  assistance  they  need  to  accomplish  their  work. 

206.  _  This  organization’s  materials  and  supplies  are  well  accounted  for  without  unexplained  losses. 

207.  _  This  organization’s  materials  and  supplies  meet  quality  specifications. 

208.  _  Organizational  members  rarely  need  to  shift  work  priorities  to  get  jobs  done. 

209.  _  Organizational  members  rarely  need  to  redo  ajob  or  task. 
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1  -  Strongly  Disagree  4  -  Somewhat  Agree 

2  -  Disagree  5  -  Agree 

3  -  Somewhat  Disagree  6  -  Strongly  Agree 

The  organization’s  customers: 

210.  _  Are  satisfied  with  the  quality  of  work 

211.  _  Seldom  complain 

212.  _  Are  satisfied  with  the  quantity  of  work. 

The  organization’s  customers: 

213.  _  Are  satisfied  with  the  timeliness  of  work 

214.  _  Find  minimal  errors  in  the  work 

215.  _  Find  the  work  consistent. 

Scoring 

For  each  line  in  each  scoring  table: 

■  Write  the  sum  of  your  responses  for  the  range  of  statements  indicated 

■  Divide  by  the  sum  by  the  divisor  value 

■  Write  the  result  in  the  score  column 

■  Compare  your  score  with  the  target  value  for  each  quality 

Scores  less  than  the  target  indicate  improvement  areas  or  potential  problem  areas  with  respect  to 
implementing  process  improvement  projects. 

While  this  assessment  focuses  on  quality  and  quality  improvement,  most  of  the  statements  can  be  taken  in  the 
context  of  process  improvement  without  loss  of  validity  in  the  scoring  tables. 

One  of  the  most  valuable  deliverables  in  this  assessment  is  the  list  of  qualities  that  should  be  of  concern  to 
change  management  as  well  as  process  improvement  teams. 
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Organtza^onat  Ctimata 


tS¥lK)r  I  'Score 


Awareness  of  strategic  challenge 


Vision  for  the  future 


Innovation 


Quality  policy 


Value  system/ethics 


Top  management  involvement 


Visible  commitment  to  goals 


Role  in  improvement  process 


Concern  for  improvement 


System  for  improvement 


Awareness  of  issues 


Attitudes  and  morale 


Cooperation 


Involvement 


Perceptions  of  work  place 


Social  interactions 


Task  characteristics 


Consequential  constraints 


Customer  orientation 


Communications 


Avg  score — Divide  sum  by  20  = 
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Process 


1.50 

Job  analysis 

1.50 

Higher  authority 

1.70 

Quality  emphasis 

1.55 

Top  management  leadership 

1.60 

Customer  service 

1.60 

Define  improvement 

3.50 

Unit  goals 

3.50 

Organizational  goals 

1.50 

Quality  planning 

1.50 

Planning  strategy 

3.50 

Organizational  streamlining 

3.50 

Investment  in  technology 

3.50 

Methods/process 

improvement 

3.50 

New  ideas 

1.40 

! 

People-oriented  input 

3.50 

Track  progress 

1.50 

Measurement 

1.40 

Feedback 

DoD  Quality  and  Productivity  Self-Assessment  Guide 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


G-20 


DoD  Quality  and  Productivity  Self-Assessment  Guide 


Framework  for  Managing  Process  Improvement:  A  Guide  to  the  Methodolgy 


mente 


Dh/^or  Score 


Quality 


3.50  Work  flow/delays 


3.50  Waste 


3.50  Tools/equipment 


3.50  Staffing 


3.50  Facilities 


3.50  Training 


3.50  Supplies/parts 


3.50  Organization/group  structure 


3.50  Customer  quality  survey 


3.50  Quantity 


3.50  Reliability 


Avg  Score— Divide  sum  by  11  = 
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ANNEX  H.  METHODOLOGY  WORK  BREAKDOWN  STRUCTURE 


PHASE  1:  STRATEGIC  AND  BUSINESS 

PLANNING 

Step  1:  DevelopA^alidate  the  Strategic  Plan 

T  1 :  Develop/validate  the  organizational 
articles  of  faith 

T  2:  Identify  major  customer  groupings  and 
general  customer  requirements 
T  3:  Conduct  strategic  benchmarking  to 
establish  performance  targets 
T4:  Conduct  SWOT  analysis 
T  5:  Identify  core  competencies 
T  6:  Determine  high-level  customer  service 
requirements 

T  7:  Prepare  breakthrough  objectives 
T  8:  Identify  performance  measures 
T  9:  Document  the  strategic  plan 

T  10:  Review  and  approve  the  strategic  plan. 

Step  2:  DevelopA^alidate  the  Business 

Systems  Plan 

Til:  Review/validate  the  current  business 
systems  planning  architectures 

T  12:  Identify  major  business  processes 

T  13:  Develop  the  business  process/ 
organizational  map 

T  14:  Prepare/validate  information  systems 
architectures 

T  15:  Review  and  approve  the  business 
systems  plan. 

Step  3:  Develop/Validate  the  Business  Plan 

T  16:  Review  strategic  and  business  systems 
planning  materials 

T  17:  Develop  preliminary  process  notebook 

T  18:  Conduct  detailed  customer  requirements 
analysis 

T  19:  Categorize  process  improvement 
projects 

T  20:  Develop  the  business  plan  report 

T  21 :  Review  and  approve  business  plans. 

Step  4:  Construct  Performance  Cells 

T  22:  Select  performance  cell  by  process 

T  23:  Assign  responsibility  for  performance 
cell  development 


T  24:  Develop  performance  cells 

T  25:  Review  and  approve  the  performance 
cell  document. 

Step  5:  Establish  Process  Improvement  Project 

T  26:  Specify  process  improvement  project 

T  27:  Select  and  confirm  a  process  manager 
and  project  manager 

T  28:  Develop  and/or  validate  the  process 
deployment  map 

T  29:  Record  functional  management 
considerations 

T  30:  Document  the  scope/mission/objectives 
of  functional  elements 

T  3 1 :  Select  and  train  the  cross-functional 
process  improvement  team 

T  32:  Develop  a  preliminary  process  vision 

T  33:  Develop  the  process  improvement 
strategy 

T  34:  Develop  the  project  plan 

T  35:  Review  and  approve  the  project  plan. 

PHASE  2A:  BUSINESS  PROCESS 

REENGINEERING 

Step  6:  Conduct  Baseline  Analysis 

T  1 :  Develop  or  confirm  the  project  scope 
T  2:  Develop  or  review  and  revise  AS-IS 
Activity  Models 

T  3:  Develop  or  review  and  revise  AS-IS 
Data  Models 

T  4:  Perform  activity  based  costing 
T  5:  Perform  time-line  analysis  (simulation) 
T  6:  Document  the  baseline  condition 
T7:  Revise  performance  cell  descriptions 
T  8:  Review  and  approve  baseline 
documentation. 

Step  7:  Conduct  Improvement  Analysis 

T  9:  Review  process  vision,  objectives,  and 
measures 

T  10:  Conduct  stakeholder  requirements  gap 
analysis 

Til:  Conduct  best  practices  benchmarking 
analysis 

T  12:  Select  data  gathering  and  analysis 
techniques 
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T  13:  Identify  and  document  performance 
gaps  in  product  quality 

T  14:  Identity  and  document  performance 
gaps  in  process  cycle  time 

T  15:  Identify  and  document  performance 
gaps  in  process  cost 

T  16:  Identify  and  document  process-related 
issues 

T  17:  Identity  and  document  organizational 
issues 

T  18:  Identify  and  document  technology 
issues 

T  19:  Develop  process  improvement 
opportunities 

T  20:  Prepare  process  improvement  analysis 
report 

T  21 :  Review  and  approve  process 
improvement  analysis  report. 

Step  8:  Redesign/Reengineer  Processes 

T  22:  Review  process  improvement  analysis 
report 

T  23:  Refine  process  vision  statement 

T  24:  Develop  initiatives  for  process 
improvement 

T  25:  Redesign/redevelop  business  processes 

T  26:  Refine/redevelop  process  deployment 
map 

T  27:  Describe  and  quantify  new  stakeholder 
relationships 

T  28:  Revise  future  state  performance  cell 
descriptions 

T  29:  Validate  initiatives  and  models  against 
requirements 

T  30:  Select  alternatives  for  process 
improvement  actions 

T  3 1 :  Perform  economic  analysis  on 
alternatives 

T  32:  Develop  detailed  TO-BE  activity  and 
data  models 

T  33:  Initiate/coordinate  data  administration 
activities 

T  34:  Initiate/coordinate  information  systems 
activities 

T  35:  Prepare  final  process  design 
specifications 

T  36:  Review  and  approve  process  design 
specifications. 


Step  9:  Prepare  Functional  Economic  Analysis 
Decision  Package 

T37:  Review  process  improvement 
recommendations 

T  38;  Review  organizational  change 

management  plan  (from  Section  6.3.5) 

T  39:  Review  technology  change 

management  plan  (from  Section  7.3.6) 

T  40:  Develop  preliminary  Functional 
Economic  Analysis  (FEA) 

T  41 :  Develop  preliminary  data  and  technical 
management  plan 

T  42:  Perform  technical  review  of  FEA 
documents 

T  43:  Validate/revise  preliminary  FEA  report 

T  44:  Prepare  final  Functional  Economic 
Analysis  report 

T45:  Review  and  approve  FEA 

PHASE  2B:  ORGANIZATIONAL  CHANGE 
MANAGEMENT 

Step  10:  Assess  Organizational  Capability 

T  1 :  Review  process  improvement 
organizational  implications 
T  2:  Assess  organizational  status  (strengths 
and  weaknesses) 

T  3:  Document  current  organizational  status 
T  4:  Review  and  approve  organizational 
situation  report. 

Step  11:  Identify  Organizational  Change 
Requirements 

T5:  Review  and  evaluate  process 
improvement  analysis  report 
T  6:  Document  organizational  best  practices 
T7:  Evaluate  organizational  change 
requirements 

T  8:  Develop  time  and  cost  estimates 
T  9:  Develop  organizational  impact 
statement 

T  10:  Review  and  approve  organizational 
impact  statement. 

Step  12:  Develop  Organizational  Change 
Management  Plan 

Til:  Analyze  organizational  barriers  to 
change 

T  12:  Prepare  strategies  for  overcoming 
barriers 
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T  13:  Identify  process-related  training 
requirements 

T  14:  Develop  organizational  change 
management  plan 

T  15:  Review  and  approve  organizational 
change  management  plan. 

PHASE  2C:  TECHNOLOGY  CHANGE 

MANAGEMENT 

Step  13:  Assess  Technical  Capability 

T  1 :  Review  Process  Improvement  Plan 
Technical  Implications 
T  2:  Assess  Current  Technical  Status 
(StrengthsAVeaknesses) 

T  3:  Assess  Emerging  Technologies  v 
Process  Requirements 
T  4:  Document  Technical  Status 
T  5:  Review  and  Approve  Status  Report. 

Step  14:  Identify  Technical  Change 

Requirements 

T  6:  Review  Process  Improvement 
Recommendations 

T  7:  Identify  Technology  Best  Practices 
T  8:  Evaluate  Technical  Change 
Requirements 

T  9:  Develop  Time  and  Cost  Estimates 

T  10:  Perform  Technical  Impact  Statement 

Til:  Review  and  Approve  Technical  Impact 
Statement. 

Step  15:  Develop  Technical  Change 

Management  Plan 

T  12:  Design  High-level  Technical  Models 

T  13:  Identify  Barriers  to  and  Implications  of 
Change 

T  14:  Develop  Strategies  for  Addressing 
Barriers 

T  15:  Identify  Technology-related  Training 
Requirements 

T  16:  Develop  Technology  Change 
Management  Plan 

T  17:  Review  and  Approve  Technology 
Change  Management  Plan. 

PHASES:  ENTERPRISE  ENGINEERING 

Step  16:  Conflgure  Technical  Platform 

T  1 :  Review  Approved  FEA  Package  and 
Supporting  Documents 


T  2:  Review  Technical  Change  Management 
Plan 

T  3:  Assess  Current  Status  and  Capabilities 

T  4:  Design  Hardware  Systems  Support 
Requirements 

T  5:  Design  Communications  Support 
Requirements 

T  6:  Design  Network  Support  Requirements 

T  7:  Design  Systems  Software  Requirements 

T  8:  Document  Technical  Platform 
Requirements 

T  9:  Review  and  Approve  Platform 
Requirements. 

Step  17:  Develop  Application  Systems 

T  10:  Review  Approved  FEA  and  Supporting 
Documentation 

Til:  Review  Technical  Change  Management 
Plan 

T  12:  Assess  Current  Capabilities 
T  13:  Design  Application  Support  Systems 
T  14:  Develop  Application  Support  Systems 
T  15:  Unit-test  Application  Support  Systems 
with  Data  Base 

T  16:  Document  Application  Support  Systems 
T  17:  Review  and  Approve  Application 
Systems. 

Step  18:  Develop  Data  Base  Structures 

T  18:  Review  Approved  FEA  and  Supporting 
Documentation 

T  19:  Review  Technical  Change  Management 
Plan 

T  20:  Assess  Current  Capabilities 
T  21 :  Perform  Data  Base  Administration 
Activities 

T  22:  Design  Data  Base  Structures 
T  23:  Unit-test  Data  Base  Structures  with 
Application  Software 
T  24:  Document  Data  Base  Structures 
T  25:  Review  and  Approve  Data  Base 
Structures. 

Step  19:  Construct  Information  Systems 
T  26:  Prepare  Test/Pilot  Site  for  Systems 
Assembly 

T  27:  Load  Test  Files  and  Data  Bases 
T  28:  Assemble  and  Test  Application  Systems 
T  29:  Develop  Draft  Information  System 
Manuals 

T  30:  Conduct  Initial  Training 
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T  3 1 :  Conduct  Acceptance  Trials 
T  32:  Develop  Data  Acquisition  Plan 
T  33:  Review/Revise  Organizational  Change 
Management  Plan 

T  34:  Develop  Final  Documentation  Package 
T  35:  Acquire/Develop  Functional/Technical 
Training  Systems 

T  36:  Conduct  Systems  Audit  and  Acceptance 
Tests. 

Step  20:  Design  Systems  Integration  Plan 
T37:  Design  Platform  Integration  Plan 
T  38:  Design  Data  Base  Integration  Plan 
T  39:  Design  Application  Systems  Integration 
Plan 

T  40:  Review  Information  Systems  for 
Conformity  with  DoD  Enterprise 
Model 

T  4 1 :  Identify  and  Resolve  Cross-Functional 
Process  Issues 

T  42:  Identify  and  Resolve  Interoperability 
Issues  and  Concerns 
T  43:  Develop  Revised  (TO-BE) 

Architectures 

T  44:  Update  Defense  Data  Repository 
System 

T  45:  Develop  Transition/Migration  Plan 
T  46:  Conduct  Pre-installation  and 
Deployment  Conference. 

PHASE  4:  PROJECT  EXECUTION 

Step  21:  Develop  Installation/Deployment 

Project  Management  Plan 

T  1 :  Review  Approved  Project-related 
Documents 

T  2:  Construct  Project  Management  Plan 
T  3:  Secure  Review/Approval  of  Project 
Management  Plan 

T  4:  Execute  Project  Management  Plan. 

Step  22:  Install/Deploy  Information  Systems 
T  5:  Select  Initial  Installation  Site 
T  6:  Install  and  Test  Information  Systems 
T7:  Implement  Training  Programs 
T  8:  Conduct  Parallel  Test  Program 
T  9:  Secure  Customer  Acceptance 
T  10:  Implement  Transition  (Cut-over)  Plan 
Til:  Deploy  Remaining  Sites 


T  12:  De-commission  Obsolete  Information 
Systems 

T  13:  Conclude  Information  Systems 
Deployment  Phase. 

Step  23:  Deploy  Organization  Change 
Management  Plan 

T  14:  Issue  Policy  and  Guidance 
T  15:  Implement  Transition  Plan 
T  16:  Deploy  Implementation  Plan 
T  17:  Complete  Organizational  Realignment 
T  18:  Changeover  to  New  Process  and 
Information  Systems 
T  19:  Monitor  Change  Process 
T  20:  Adjust  Program  as  Required 
T  21:  Prepare  Final  Implementation  Report 
T  22:  Conclude  Installation/Deployment 
Program. 

Step  24:  Operate/Maintain  Process  and 
Information  Systems 

T  23:  Operate  Process  and  Information 
Systems 

T  24:  Monitor  Performance 
T  25:  Identity/Classify/Resolve  Problems  and 
Issues 

T  26:  Maintain  Process  and  System 
Documentation 

T27:  Conduct  Continuous  Training  and 
Support  Program 

T  28:  Prepare  Regular  Operating  Status 
Reports. 

Step  25:  Conduct  Continuous  Process 
Improvement  Program 

T  29:  Review  Performance/Status/Problem 
Reports 

T  30:  Conduct  Surveys/Interviews/ 
Questionnaires/Focus  Groups 
T  3 1 :  Monitor  Stakeholder  Feedback 
T  32:  Identify  Incremental  Improvement 
Opportunities 

T33:  Design  Incremental  Change 
Specifications 

T  34:  Implement  Incremental  Change 
Program 

T  35:  Prepare  Regular  Improvement  Status 
Reports. 
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